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SUKKARY 


Volume IV describes the IPAD system design. The design is 
based upon the requirements identified in the aircraft design 
process and computational requirement studies documented in 
Volumes II and ITT respectively. Tables 1 through U summarize 
the relationship of these requirements to the IPAD system design 
features, the IPAD software requirements and host operating 
system requirements. 

These requirements reflect the user's environment. His 
tasks are not completed in a day or with a single run on the 
computer. His interface with the computer should be with 
language and devices that give him capabilities he needs without 
loading him with jargon and irrelevancies. He works in large 
organizations where free communication is essential. Dut he 
also works with vast volumes of data that must be controlled and 
kept in a high state of integrity. The organization he works 
for has a vested interest in his work and an interest in 
maintaining some security on the results of his work. At the 
same time, th^ user is a creative individual and requires some 
privacy for thought and invention. The product he is designing 
is highly complex and he must work under rigid schedules. 
Reliability of the computing system and the data base is 
critical. Those factors are dealt with ir the design of the 
IPAD system. 

The IPAD system is designed to manage data on the project 
level. Project data and application software are treated as an 
entry in the data base. The organization of application 
software into sequences to perform some particular task is 
supported by executive type routines. The execution of module 
sequences and the handling of data are supported by the host 
operating system and the IPAD data manager. Personal terminals 
are the principal interface and dialogue language is the 
principal means of communication. 

Top-down structured programming is the design method. In 
this method, the system is systemat ically refined from the most 
general statement of requirements to the most specific. The 
IPAD system design was refined to where host system hardware and 
operating system software, not yet specif'i'od, began to have a 
major impact. 

Human factors, security, and standards were studied in 
detail and recommendations are given, A survey was made of 
manufacturers of large scale computing hardware to obtain 
performance and size characteristics of basic hardware 
components.' The results of this survey were utilized to 
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formulate a CDC 6600 (CYBER 74) and an IBM 370/168 configuration 
adequate for a large aircraft design project. 

The acceptance of application software already in existence 
and software that will be developed independent of IPAD system 
standards was studied by Control Data Corporation. They 
recommend in their report, included as Appendix C, development 
of a machine independent FORTRAN language into which the 
software can be translated. 

In this volume, answers to task questions asked in the 
original RFP from NASA are answered. They are followed by a 
detailed descriptxon of the basic design reguireroents. The 
design requirements are then transformed into a functional 
design that gives a broad diagramatic and conceptual overview of 
the system. Finally, detailed design specifications of the 
system are given. 
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Table I IPAD Design Requ i rement— Conti nu ity Over Task and Time 



CONTINUITY 

OVER TASK AND TIME 



IPAD SYSTEM 

IPAD SOFTWARE 

HOST OPERATING SYSTEM 

DESIGN REQUIREMENTS 

DESIGN FEATURES 

REQUIREMENTS 

REQUIREMENTS 


Continuity of day~ to-day 
work 

• Subtask interruption and 
restart 

4 

• Unique identification of 

subtasks 

• Saving/ retrieving subtask 

1 ibrary 

• Subtask setup 

® User log off with job 
executing 

Flow of information 
throughout the user 
community 

• Community library and its 
associated support routines 

• Data display 

• information retrieval 

• Expl icit/lmpl icit l/O 

• Unique names 

• Qualifiers 

• Data management disci pi ine 

and conventions 

Project plans and progress 
related to the user’s 
day-to-day work 

• Subtask setup and termination 
linked to project plans and 
reports 

• Connecting user log-on/off 
to plans and reports 

Continuous user capability 
while migrating across 
computers 

• Machine independent high 
level design 

® High level code in the IPAD 
system written in machine 
independent source 
statements 


Time sharing system 

— multi tasking 

— relationship to IPAD executive' 

— allowable terminal disconnect 

during execution 

Permanent file system 


• Permanent file system 

* Data management utilities 



• Compiler for a machine independent 
language 
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Table 2 IPAD Design Requirement — User \ , Interface 


( USER INTERFACE 

DESIGN REQUIREMENTS 

IPAD SYSTEM 
DESIGN FEATURES 

IPAD SOFTWARE 
REQUIREMENTS 

HOST OPERATING SYSTEM 
REQUIREMENTS 

?artoni1 Temliul 

9 Unique user ID for aach 
parson 

9 Support for typical taminal 
activltiai 

a Uaar ID tablaa 

aLogIcto aupport tanalnal type 
activltlaa 

a Tina eharing eyataai aupport Ing tha 
approprlata type of taminal 

Functional Capabllltlaa 

• Dafina Varlablaa 

• Enter coda and data 

• Tranafarring lnforaatlon\ 

within IPAD 1 

• Sanding Infomatlon I 

outalda IPAD ' 

a Edit coda and data 
a Purge Infonutlon 

a Coaipara Infomatlon 

a Conatruct jobt tor 
aaacutlon 
a Eiacuto Joba 

a DIaplay Infomatim | 

a Find Infonutlon | 

a Learning about IPAD 

9 Defining library entrlaa or" 
varUblei 

• Creating library antriei 

• Dlapoaition of library 

entries 

• Modifying library entries 

• Disposition of library 

entries 

• Displaying results 

• Construct an OH sequence at 

a Job 

• Execute a Job 

e Displaying results 

• Searching through the 

libraries 

• Oltpiaylng retuits 

• Searching through the 

libraries j 

9 Learning about IfAO 

► 

a Executive and data nanagatnant 
aoftwara 

a Teaching aoftwara 

• Executive and data managanent 
software support 

0enttr«1 Control Conmandi for 
9 Pftuoing ^ 

9 Continuing f 

9 U>g-off < 

9 U^aaOn 

9 AMltUnci 

aintarruptad Atatai 

a OparatIng ayatm log-off, . 

IPAD log-off 1 

a OparatIng ayaten log-on, j 

IPAD log-on ) 

a Learning about IPAD 


a Expcutlva logic worhlng with 
the oporatlng ayatam 

a Subtaah aatup and Interruption 
logic 

a Teaching aoftwara 

9 Roll out, roll in controllable by a 
user program 

* Terminal interface for )og*on and 
log -off 

Handling of Infonutlon 
Inalda IPAD la Invialbla 
to the uaar 

9 Stored data definition 

9 Coding moduletopsratlonal 
modulef and Job 
organization 

• Support for the atored data 
definition and automallc 
library entry handling for 
constructed Jobs 

• Flit assignments changeable by a 
user program 

Hunan factors 

• Interactive dialogue eetphasla 
with helps to aid users at 
various level a of 
proficiency 

• Intoractive logic in the code< 

9 Monologue^ dialogue end teach, 
modes 

• Interactive support to the uaer 
Proper response time characterletics 




























Table 3 IPAD Design Requirement — Privacy, Security, Control, and Integrity 


PRIVACY, SECURITY, CONTROL, AND INTEGRITY 

DESIGN REQUIREMENTS 

IPAD SYSTEM 
DESIGN FEATURES 

IPAD SOFTWARE 
REQUIREMENTS 

HOST OPERATING SYSTEM 
REQUIREMENTS 

Private and public data 
regions 

0 Subtask 1 ibrary 
0 Community 1 ibrary 

0 Data management support 

for this library structure 

0 Permanent file system 

0 

• Data management utility routines 

Protection against illegal 
^'access to information 

0 Data access Permission codes 

0 Command access permission 
codes 

0 Security control of access 
codes 

0 Access code checks 
0 Permission code checks 

0 Specialized procedure for 
setting codes 

• Permanent file system with security 

lockout f 

* Central memory read/write protection 


Assurance of the integrity 
of the data base 


« Unique names for all library 
entries 

9 Mandatory version numbers 
for all altered 1 ibrary 
entries 

• Automatic qualifier generation 

to record the origin of 
the data 

• Trace of information leaving 

IPAD 

• Protection against 

self-inflicted accidents 

• Setting of permission and 

access codes 

0 Controlled relationship 
between the project and 
its subtasks 


0 Checks for name uniqueness 
0 Version number generator 

0 Qualifier generator 


0 Keeping records for all 
information leaving IPAD 

0 Warning about the 

implications of certain 
actions 

0 Provision for handling such 
codes in project plans 

0 Ability to control subtasks 
on the basis of information 
in the project plans 


Permanent file names with qualifiers 
and version numbers 


ORIGINAL PAGE 1& 
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1.0 INTRODUCTION 


Integrated systems have generally been developed to support 
a technical analysis requirement without consideration for the 
information control and communication requirements of the 
project organization. Within large project organizations, the 
communication ot information between specialized groups is 
essential. The critical factor in communication is the volume 
of information being controlled, transmitted or interpreted. As 
volume increases, response times get longer, reliability 
deteriorates, control diminishes and information becomes more 
obscure. 

Lo nger Resp onse Time - In figure 1,1, response time is plotted 

against volume of information for several transfer rates. There 
is a band of response times that is effective for a given 
activity. Response times above this band result in information 
being transferred too late to be useful to the receiving 
organization. 



Figure l.l Effect of Information Volume Increase 
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Besponse time is dependent upon the device used. For 
example, if it were necessary to transfer a thousand order ten 
percent populated flexibility matrix by letter or report using 
a human typist, it would require between fifteen and thirty 
hours at a steady typing speed of fifty to one hundred words per 
minute discounting errors. Let this be response time A at rate 
i on figure 1.1. A more efficient method could be punched 
cards. If each card holds ten words and the card punch rate is 
one hundred cards per minute, the transfer time will be one and 
two thirds hours, shown as point B at rate 2 on figure 1.1. If 
magnetic tape or disc is used, the response time would be one to 
ten seconds shown as rate 3 on figure 1.1. Hence, acceptable 
response times are volume and device dependent. 

De terioratin g Re liabili ty - As the volume of information 

increases the ability of humans to maintain reliability 
decreases. Hence, a capability must be sought that will provide 
-nearly perfect reliability and still -im-ve—the txan'sf'eT-'r'arte 
necessary to produce the required response times.. 

Diminishing Co ntrol - An organization is managed by a small 
number of individuals. Data is generated and used by a large 
number of individuals. Control of creation and changing of the 
data base is dependent upon the ability to collect and contain 
the data in a manageable form. Hence a capability is required 
to store the data base and provide control methods. 

Obscuring ot Informati on - The thousand order flexibility matrix 
in the previous example, coupled with a load matrix,— contains 
the deflections for a thousand points, but it does not 
communicate those deflections to a user unless acted upon in 
some way. Hence, for high volumes, methods are necessary to 
manipulate, extract, and display the precise information needed 
by the user to make a decision. 

The problem is aggravated and compounded when several 
disassociated groups become involved such as two or more 
companies or a company and a government agency. In these 
instances, local jargon and definitions, local methodology, 
local data formatting and local preferences become part of the 
prob lem. 

Boeing's IPAD system design exploits the capacity of the 
computer to process, transmit, and store data rapidly and 
reliably to augment man's ability to communicate. 
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2.0 ANSWESS TO TASK 2 QUESTIONS 1, 2, 3, 12, AND 13 


Answers to Task 2 questions which relate to the IPAD system 
design are presented in this section. The remaining Task 2 
questions which relate to the support of the design process are 
answered in volume II and those which relate to the user 
requirements are given in volume III. 

Task 2^ Question 1 — How should the (IPAD) system be 

organized to provide sufficient flexibility to accommodate 
independently developed codes, pre-existing and/or those created 
in the future? 

The system organization should be able to accommodate 
multiple language processors, either compilers or translators 
and provide a mechanism for data structure transformations. 

TPAD should accept other language processors to either 
directly compile to object code for a native mode version of the 
application code, or to provide language converters for 
interfacing with major existing languages- The burden for 
development of these converters would be decided on a case by 
case basis. 

The stored data definition is the mechanism for interfacing 
inconsistent data structures. The user must supply such a 
definition for each data structure type and’ logic must be 
provided to convert from one to the other. When this is done 
for a particular convention, all other sets of pre-existing code 
using the same conventions may then enter the system without 
additional effort to define the data structure conventions. 

Task Ques t ion 2 — What computer languages will be 

admissible in the pre-existing codes? 

There will be a standard OH language for IPAD (see Volume 
VI). Additionally, any language that’ is acceptable to the host 
operating system is acceptable to IPAE, although the user may 
have interfacing problems between codes of different languages. 
IPAD will execute any code compiled on the host system, but 
cannot automatically interface data between codes having 
different input/output conventions (see question 1). 

IPAD is not dedicated to working with one language in its 
library of coding modules. Since IPAD is using the host 
operating -system for as many utilities as possible, any compiler 
that can be called as a system utility is acceptable. The 
consequences of the use of arbitrary languages are: 
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o Input/output data structures say not interface with 
current IPAD data. 

o Any or all of the specialized IPAD features may never 
be usable. 

o An unknown quantity of machine dependence may be 

introduced. 

Task 2 j 5 Questio n 3 — What degree of machine independence 

is acceptable to IPAD? 

Machine dependent code should be restricted to those areas 
concerned with the host system interface. No portion of the 
IPAD system communicating directly with the user should be 
machine dependent; i.e., the user interface logic should be 
independent of the host system. Machine dependent code for 
efficiency purposes should be done only after the performance of 
machine independent code is clearly demonstrated to be 

unacce ptable. 

Ta sk 2, Q uestio n 1 2 — What will be the impact of the next 
generation computers on IPAD? 

Quantitatively the question is not answerable at this time. 
Qualitatively the following areas could be affected; 

o increasing size and reliability of the data base, 

o introduction of new source language capability 

matching new hardware logic, 

o larger number of simultaneous users possible, 

o greater involvement in multi-machine networks . 

The primary aspects of fourth generation computers which 
could affect IPAD are: 


o 

array type arithmetic. 


o 

virtual memory. 


0. 

distributed computing logic. 

o 

significantly faster CPU 

opera tions 

o 

larger auxiliary storage 

devices. 
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Some of these are direct benefits and some aill require IPAD 
system modifications' and internal redesign in order to receive 
significant benefits. 

T ask 2, Question 13 — What is the first release capability 
for IPAD which should be developed for subsequent extension. 

Specific capabilities for three phases of IPAD development 
are given in table 2.1. 

Table 2.1 is related to the design nodes of section 6.2. 
Continuity in task and time is the primary aim of the first 
release system and emphasizes the following features; 

o subtaslc and community libraries, 

o continuity of the user’s activities through the 
subtask concept, and 

o constructing and executing jobs. 
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Table 2-1 IPAD Development Recommendations 


FUNCTION AND KEY FEATURES 


IPAD DEVELOPMENT PHASE 


2 


Subtask Set Up 

• Connection to project plans 

• Initial izing of STL 

• Recovery of STL with 
executing STS 


None Partial 
Partial Partial 
Partial Partial 




Subtask Command Mode 

• Command decoding 

• Utility set up and calling 

• STS interruption/restart 





Subtask Step Controlled Abort 

• File clean up 

• STS termination 

Subtask Interruption 

• STL preparation for recovery 

• Execution after sign off 

Subtask Termination 

» Tie into plans 

• Tie into report 

• File disposition 

• Keeping ST records 

Learning About IPAD 

• Teaching mode 

• Automatic tie-in to each 
command 

Searching Through the Libraries 

• Display capabilities for 
all LE 

• Selection criteria 

Creating Library Entries 

• Entering code 

• Entering data 

• Convenient transformations 


Partial 

Full 


Full 

Partial 


Partial 


None Partial 

None Partial 

Partial Full 
Partial Partial 


Partial 

Partial 


Partial Partial Full 
Partial Full 


Impl icit I/O 


Ful 1 
Full 
None 
Partial 


Partial 

Partial 











Table 2.1 IPAD Development Recommendations (Cont'd) 









3.0 DESIGN REQOIBEHENTS 


The user requirements are the driving consideration in the 
IPAD design- The IPAD system that is implemented will be a 
balance of user requirements against software and hardware 
constraints to achieve an improvement in cost, timeliness, 
and/or technical capability over methods currently in use for 
product design. 

The basic user requirements for the IPAD system are: 

a) Continuity over task and time 

b) User interface 

c) Privacy, security, control, integrity 

d) Reliability 

The dominating requirements are a) and c) . Taken in their 
broadest sense they imply 

a) a system that supports direct communication of 
technical information between organizational entities; 

b) a system that accepts as a single task, work involving 

many users that runs over time periods of days, weeks 
and months; 

c) a system that supports all of the computational, data 
storage, data display, data management, and data 
communication requirements of an entire organization 
engaged in the development of a product or products, 
and; 

d) design control both through the automatic data 

management and integrity controls built into the 
system and through controls made directly available to 
the management of the organization. 

In this section the user requirements, independent of current 
software and hardware constraints, will be described. 
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3.1 CONTINUITY OVER TASK AND TIME 

The design process flow charts developed in Volume II are 
representative of the type and. organization of tasKs necessary 
to design an air vehicle. However, they are only 
representative. The process actually followed will be an 
outgrowth of the product being designed, the organizations 
involved and the preferences of individuals at every level. 
Hence, a computer system designed to only perform the tasks and 
seguences shown in Volume II would have short term value to some 
parts of the aerospace industry and very limited value to the 
industry as a whole. To overcome this limitation, a study was 
made of the general design environment. It was found that 

continuity of activity and data over task and over time was an 
essential characteristic of the design environment. Continuity 
over task and time affects the design process in the following 
ways: 

a) Organizational Hierarchy 

b) Integration of Individual Contributions 

c) Phasing of Design Levels 


Organi zat i onal Hierarchy - There is a hierarchy of planning and 
control associated with the development of a product. 
Information flows continuously through the hierarchy as shown in 
figure 3.1. The terms in the parenthesis are basic descriptors 
of the primary interest at each level. While the labels of 
company, product, etc. are somewhat arbitrary, there are several 
characteristics that seem universal. 

a) There is a level at which real work on the product 
design is accomplished. Above that level, work is 
centered around planning and management control. 
Below that level, work is centered around preparation 
of tools and methods. In the hierarchy shown in 
figure 3.1, the level of real work on the product is 
at the subtask level. 

b) Each level tends to transmit information above and 
desire action from below. 

c) Those above tend to be interested in what is being 
done; those below tend to be interested in how things 
are done; while the user concentrates on the actual 
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Figure 3.1 Organizational Hierarchy of Product Design 


work, varying his interest between what, and how 
depending- on the immediate situation. 

d) The number of levels is not uniquely six, but it is 
neither large nor small compared to six. 


Integration of In divid ual Co ntributions - A user of IPAD will 

execute a job, several jobs, or the same job several times in 
order to complete a subtask. The same user and other users will 
complete other subtasks, which, together, will form a task. 
Many tasks may be required to complete a project (which may be 
a product) . Figure 3.2 illustrates this relationship. 
Projects, tasks, subtasks, and jobs may be large, small, or 
nonexistent depending on the circumstances. Some possible 
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examples are given in figure 3.3. On large projects, the number 
of users may be many hundreds and the volume of data may be of 
the order of billions of words. Each individual working on the 
project both receives and contributes data and information. The 
effectiveness of each individual contribution depends upon the 
effectiveness of his ability to communicate. 

Phas in g of Design Lev els - In the. studies performed in Volume II 
several levels, or phases, to the design process were defined. 
A different design function is performed at each level. Each 
level has its own characteristics of time, data volume, 
technology required, etc. These levels will typically be time 
phased as shown in figure 3.4 In general, each succeeding level 
represents a refinement of the product design. Essential 
information in the form of data and conclusions is passed 
between the levels, as necessary, to ensure continuity of the 
design process. 



Figure 3.2 


Project Growth 








PROJECT 

FIND BEST 
SST 

FIND BEST 
DaTA-WING SST 

FIND USES FOR 
S.A.S. ON AN SST 

NONE 

TASK 

FIND BEST 
DELTA-WING SST 

(Configure 

IN level III 

USE S.A.S. TO 
IMPROVE RIDE 
QUALITY 

NONE 

SUBTASK 

CONFIGURE 
IN LEVEL III 

FIND BEST 
CONFIGURATION 
WITH SUBSONIC LE. 

CHANGE S.A.S. 
ELECTRONICS 
ONLY 

DEVELOP GENERAL- 
SWEEP THICKNESS 
TRENDS USING 
WIND TUNNEL DATA 

JOB 

(Execution) 

SUBSONIC L E. 
4-ENGINES ETC. 

4 ENGINES 
ETC. 

SYNTHESIZE 
RIDE QUALITY 
GAINS & FILTERS 

ANALYZE ONE ' 
Sn OF WIND 
TUNNEL DATA 


Figure 3.3 Examples of Projects, Tasks, Subtasks, and Jobs 


In sunimdry, the significant characteristics of this 
environment are: 

a) There is continuity in the day-by-day work within the 

organizational hierarchy, between individual 

contributors and between the several levels of 

refinement of the product design. 

b) There is a flow of information (data, directives, 
criteria, conclusions, etc.) throughout the entire 
product design community. This flow of information 
attempts to associate plans made, work done, and tools 
and methods used into a single congruent whole. 
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Figure 3.4 Phasing of Design Levels 


c) At every level of the oryanizatioo and of the design 
there are individuals doing the actual work. Those 
above give direction, review results and exercise 
control. Those below prepare tools and methods and 
supply information. 

d) Design activities are typically ongoing over periods 
extending into years and decades. 

It is a user requirement that the IPAD design be compatible 
with and provide direct software and hardware support to this 
environment- 
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3.2 OSEH INTERFACE 


Although the design process flow charts in Volume II 
represent the' procedure a typical design organization might 
follow, they do not represent the general activities users 
perform. An understanding of the general activities a user 
performs is necessary to design the IPAD system. To help gain 
this understanding, a problem solving model was developed as 
shown in figure 3.5 and given in detail in Appendix B. This 
model was useful in isolating particular capabilities so that 
the system design could be modularized effectively and general 
language statements could be developed. 

IPAD is primarily a design tool. Hence, its basic 
organization is tor a human hands~on operation using a command 
structure tnat makes the computing system essentially 
transparent to the user. As a consequence, the user is placed 
in a design environment entrre'ly co'mpa“ti'ble with his own 
behavioural characteristics and the characteristics of the task 
he is performing. The principal features of this environment 
are given below. 

a) Accessing - Accessing will be through a personal 
terminal, i.e., a terminal associated with one user at 
a time during a work session. The minimal personal 
terminal will be an alphanumeric CRT with passive, low 
resolutxon graphics. High resolution interactive 
graphics, hardcopiers, remote job entry devices, and 
other equipment will vary from installation to 
installation. 

b) Capabilities - The IPAD system will provide the 
following capabilities: 

1) DEFINE - Entering or modifying, definitions in the 
IPAD libraries. The definitions include 
abstracts, variable names, correspondence tables, 
and other information necessary to interface an 
element 'with the data base and provide 
descriptive information to the user. An element 
is a data set, a module of application code, a 
display format, etc. DEFINE is separate from 
ENTER to allow, for example, predefinition of 
variables pertaining to a data set by a single 
focal point followed by the actual entry of data 
by other persons who must then conform to the 
predefinition. 
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PLAN The determination of objectives and constraints which 
define a desirable product and the development of a 
plan of activities to achieve these objectives within 
the constraints. 

PREPARE Setting up to do work. 

MODIFY Altering preparations to do work when it can be done 
without changing the plan. Generally, this is due 
to contingencies which are minor relative to the 
overall plan. 

WORK The activity which aims directly towards completion 
of a meaningful step in the plan. 

R EPO RT Recording and/or making visible the results of 

WORK and determining if the planned work is done. 


Figure 3.5 General Work Flow 
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2) ENTER - Entering the actual library element. 
This permits the user to enter information which 
conforms with the definition made using DEFINE. 
Many sets of information may be entered following 
a single DEFINE, but each will have qualifiers 
supplied by the user and the system to fully 
identify and distinguish them. 

3) TRANSFER - Moving elements between libraries 
within IPAD. This allows movement of elements 
between private and community libraries. It does 
not allow movement of information to a location 
remote to the IPAD installation. 

4) SEND - Sending library elements to a location 
remote to the IPAD installation. 

5) EDIT - Locating and modifying existing library 
elements. Automatic version changes will be made 
by the system to accurately trace antecedents and 
preserve integrity tor other users. 

6) PURGE - Erasing entire library elements. System 

controls will exist to ensure against purging of 
elements still being used or saved by some 

segment of the user community. 

7) COMPARE - Making comparisions between sets of 

information or between information -within the 
system and information supplied by the user. 
This would allow, for example, a check of all 
moduli of elasticity within a data set to ensure 
they ace within a given range. 

8) CONSTRUCT - This triggers a dialogue mode in 

which the user may form executable code from 
groupings or modules of code previously entered 
into the system, 

9) EXECUTE - This causes a particular set of code 

formed through CONSTRUCT to be executed. If the 
executing code has a language structure of its 
own, the user will interact in that language with 
complete transparency of the IPAD system. 
Commands will be available to interrupt an 
executing code set to review its progress, change 
its direction, or discontinue execution. 
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10) DISPLAY - Bringing information from an IPAD 

library to a display device. Display formats may 
be entered separately through a DEFINE and ENTER. 
There will be many display formats, each 

providing a particular class of display. 

Generally, activation of the display will trigger 
dialogue to guide the user in inputting necessary 
parameters. 

11) FIND - Locating information within the libraries. 

This provides two capabilities; (a) locating 

particular sets of information such as technical 
code or data sets, and (b) locating particular 
items within a data set. 

12) MESSAGE - Sending messages through the IPAD 

system to another user. 

13) LEARN - A tutorial state that provides a 

programmed learning course in the use of IPAD. 

In addition to the specific capabilities defined 
above, the -system will also provide tor (a) short term 
pauses and returns allowing execution of other 
capabilities between the pause and the return, (b) 
long term interruptions extending over log-offs and 
log-ons, {c) help from the system to the user to 
prompt him, tell him of missing information, explain 
commands which he has obviously misunderstood, and 
otherwise smooth and assist the execution of work. 

c) Communication - The transfer of data between 
application modules or between application modules and 
the systetn libraries will be transparent to the user. 
The actual locations of stored information will not be 
known to the user. Rather, movement or communication 
of information will be accomplished by the user 
through command statements utilizing generic names and 
adjectives. 

d) Human Factors - IPAD is a “hands-on” design oriented 
system. Hence, the characteristics of the user are an 
important consideration and include: 

1) the characteristics of the human mind, 

2) the experience or state of proficiency of the 
user, and 
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3) the characteristics of the task being performed. 


3.3 PBIVACY, SECUBITY, CONTROL, INTEGRITY 

a review of the design process flow charts in Volume II and 
the manner in which an organization would proceed to work these 
projects indicate reguirements for privacy, security, control, 
and integrity of system code, application code, and data- These 
requirements are as follows: 

a) There is a need for both private and public data 
regions. Private data regions provide’ space where an 
individual user can do scratch work, correct errors, 
etc. Public data regions provide space where data 
important to many users can be stored, accessed, and 
controlled. 

b) There is a need to protect information against 
unauthorized access. 

c) There is a need to control use of the system and of 
the data base. 


3.4 RELIABILITY 

The reliability of the IPAD system, hardware, and operating 
system should be such that system unreliability need not be a 
specific planning consideration for IPAD users. No definitive 
studies have been made to establish the precise parameters and 
ranges within which this criteria is satisfied. Nevertheless, 
it IS an essential criteria. 

The reliability of application modules is outside the 
control of the IPAD system. However, standards should be 
established and a rating system developed and implemented 
whereby application modules can be classified according to 
established levels of reliability. 
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4.0 DEFINITIOKS AND ABBEEVTATIONS 


Activity 
Record (AE) 


Coding 
aodule (CK) 


Community 
Library (CL) 


Data Manager System 
(DHS) 


Explicit Input/Output 


IPAD Data Base 


IPAD Executive (IE) 


Implicit Input/Output 


Job (d) 


- Part of a subtask library entry, 
setup by IPAD for use in subtask 
communication, documentation,' 
recovery, and accounting. 

- A specific collection of symbolic 
code that contributes to the 
definition of one or more opera- 
tional modules. 

- The set of all programs, data, and 
reference information available to 
the total community of IPAD users 
at any given installation. 

- The collection of software 
responsible for information flow into 
and out of the IPAD data base. 

- Input/output action to/from a library 
entry which is under the control of a 
user program. The data manager is 
responsible only for the library entry 
as a unit, and, in general, is not 
capable of inter preting-the contents 
of any library entry handled in this 
way- 

- The collection of all information 
contained in the community and 
subtask libraries. 

- That portion of the IPAD software used 
to control the basic IPAD functions. 

It is the primary interface to the 
user, 

- Input/output action which is under 
control of the data manager. 
Information transfer by the data 
manager is in terms of library 
variables. 

- A specific sequence of executable 
operational modules and/or other jobs 
which produces meaningful results for 
a user. 
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Library 
Entry (LE) 


Library Entry 
Dictionary (LED) 


Library 
Directory (ID) 

Library 

Dir e_c tor y E ntx.y ( L d.E ). 


Library Text 
Entry (LTE) 


Library Tfariable (LV) 


Library Variable 
Dictionary (LVD) 


Operational 
Module (OM) 


Operating System 
(OS) 

Personal Terminal 


Project (P) 


• Project Plan 


- The basic unit of storage in the 
iPfiD data base is the library entry. 
The LE consists of a library 
directory entry (LDE) and an associ- 
ated library text entry (LTE). 

- A dictionary containing definitions 
of all the library entries in a 
library. 

- An index to all the entries in a 
library. 

- That portion of a library entry 
containing, cjojitr,©.! and. ref.erencin.g 
information for the associated 
library text entry (LTE) . 

- That part of a library entry 
containing the data associated with 
the entry name. 

- An alphanumeric data item whose 
engineering significance is defined 
to IPAD. 

- A dictionary containing definitions 
of all the library variables in a 
libra ry. 

- An executable collection of coding 
modules which contribute to the 
definition of one or more jobs. 

- The operating system for the host 
computer within which IPAD executes. 

- The electronic or electro-mechanical 
device providing the primary path 
for the user to access IPAD data 
and programs. 

- The total set of subtasks to be 
performed during a design or analysis 
effort. 

- The definition of all project tasks. 
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Project Report 


Qualified 
Library Entry 
Name (QLEN) 

Stored Data 
Definition (SDD) 


Subtask (ST) 


Sub task 
Library (STL) 


Subtask Records 


Subtask Step 


Task (T) 

Unqualified Library 
Entry Name (ULEN) 


User*s Identification 
(DID) 


Version Number (V) 


subtasks, and the associated control 
in terms of a pert-chart type network. 

- The collection of reports expected to 
be completed during the progress of 
the project. 

- An unqualified library entry name 
with a qualifier attached indicating 
a specific instance of the LEi 

- The specifications for a logical 
information structure for one or 
more library entries in IPAD. 

- A sequence of IPAD activities which 
represents a meaningful step in a 
project. 

- A library that is private to an IPAD 
user during the execution of one of 
his subtasks. Each subtask will have 
a single associated subtask library. 

- Records in each subtask library for 
the purpose of holding activity and 
other information during the life of 
the sufatask. 

- A single step occurring in a subtask, 
normally defined by a host operating 
system control card or the execution 
of a single IPAD utility program. 

- A subdivision of a project. 

- A generic or root name of a library 
entry. Specific instances of data 
may be identified by a DLEN appended 
with a version number and/or an 
additional qualifier. 

- A unique identifier associated with 
each user of IPAD, It is mandatory 
that this ID be associated with a 
person and not an activity or an 
organization. 

- An identifier appended to an 
unqualified library entry name to 
record the occurrence of a change. 
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5.0 FUNCTIONAL DESIGN DESCRIPTION 


Early methods of organizing computing tasks involved 
batching work of a similar nature and relying on well trained 
personnel to maintain a reasonably efficient operation. ' As 
volume and complexity increased, many of these administrative 
functions were shifted to the computer, leading to the present 
day ’’operating" and "monitor" systems. Each new operating 
system development had two basic objectives: 

a) more efficient processing, and 

b) new capabilities to aid the professional programmer. 

In contrast, software has not been generated which helps the 
applications user organize and manage his work. Moreover-,., most 
-operating systems axe "one run" and "one user" oriented while 
typical applications require numerous runs, spanning several 
days or months and involve many people performing inter- related 
activities. IPAD is designed to help the applications user 
manage and organize his work. It will support continuity of 
work on the computer involving many separate work sessions 
extending over long time periods and requiring communication 
between users tnrough the data base. 


5.1 PRIMARY SYSTEM FEATURES 

Full Proje ct Support - A project is a set of tasks and a task is 
a set of sub tasks. Within any project the sequence of tasks and 
subtasks is not arbitrary. Figure 5.1 is a representation of 
two projects showing the breakdown of tasks and subtasks and the 
flow of information or interdependence between them. 

There are specific items in the data base called "plans" 
and "reports" that support management definition and control of 
the work flow. Each project and subtask will be given a report 
skeleton at the time planning data is entered in the data base. 
Hence, completion of each subtask is a formally recognized event 
in IPAD- That is, the completion of the subtask can be recorded 
in a project report. If a PEET-chart type logic is used for 
planning, as shown in figure 5.1, the sequence of subtasks can 
be controlled through permission codes in the system. Managers 
and technical users can also interrogate the status of projects 
or subtasks from the project reports. 
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PROJECT A 



PROJECT B 



Figure 5. 1 Representation of Project Plans 


Co nti nu ity of Wor k - Subtasks are the prime working 

interface between IPA~ and the IPAD user. Subtasks are 
generally associated with one user and are organized within IPAD 
to provide continuity of activity. All user activity is part of 
some subtdsk which was explicitly initiated by a user and must 
be explicitly terminated. The life of a subtask is not limited 
to an artificial work boundary such as a computer run or a 
terminal session. 

The IPAD system will accept any definition of a subtask. 
In principal, a user may have any number of subtasks defined at 
any point in time, although only one would be active at a time- 

A subtask is a user's private domain ir. which he works 
individually without impacting other users. He has access, 
through the data base libraries, to application modules, utility 
modules, and data common to all users. His accessing of 
information in the data base libraries is controlled or 
restricted as necessary to protect the community nature of the 
data base. 
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Continuity of activity means that from the time the user 
initiates a subtask until he terminates it, he works with the 
sense of continuity of a single session. That is, having 
interrupted his activities for lunch, sleep, or thinking, he 
will resume activity with a subtask status identical to that at 
the time of his interruption. This continuity will be true for 
either interactive or batch type work. 

Continuity between subtasks (and hence between users) will 
be provided by the data base. As each subtask is terminated, 
the user will transfer entries of common value into the 
community Ixbrary. 

Library Structur e - The IPAD data base is organized into a 

comuni-ty library (CL) common to all users and subtask . libraries 
(STL) private to each user. The characteristics of these 
libraries are; 

a) The community library contains all application 
modules, data sets, and other information available to 
the using community in general. 

b) Community library items may be attached, copied or 
transferred to the subtasfc library depending upon 
permission codes associated with the entry and the 
subtask. 

c) The subtask library contains all application modules, 
data and records associated with a subtask. 


d) When the subtasK. is inactive, all items in the subtask 
library are logically located within ±he community 
Ixbrary. However, contents of the subtask Ixbrary are 
not accessible as community library items. 

(e) A subtask library is created when a subtask is defined 

and continues to exist until the subtask is formally 
terminated- . . ■ 

(f) A non-community library item in a subtask library is 
private to the subtask library. 

The relationship between subtask and community libraries is 
illustrated in figure 5.2. 
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5-2 WOPK RELATIONSHIPS 

Figure 5.3 shows a schematic relationship of work within 
IPAD. A project consists of 

a) Project Plans 

o Overall Project Plan 

o Individual Subtask Plans 

b) Project Reports 

o Project Summary Report 

o Individual Subtask Reports 
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Figure 5,3 Data Base and Work Relationships in IPAD 


c) Subtasks 

o All user activity in IPAD occurs in a subtask. 

o The mode of communication in a subtask is 

primarily interactive, 

o Batch mode is available. Continuity is retained 
in the subtask whether accessing is interactive 
or batch. 

o A user may have an arbitrary number of subtasks 
defined at any one time. 

o A subtask has four distinct states: defined, 

active, inactive, or terminated. 
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Records of subtasK progress are contained in the 
subtask library and are used to formulate project 
reports. 

o Communication between subtasks is through the 
community library, 

o Protocol is defined to maintain integrity of data 
in the community library. 

IPAD will provide a framework within which control and 
reporting requirements may be defined to meet the needs of the 
using organization. For example, project and task plans may be 
placed within tne system in the form of subtask sequences as was 
shown in figure 5,1. Control can then be exercised such that 
subtasks can only be initiated as preceding subtasks are 
terminated and subtasks cannot be terminated until subtask 
reports are entered in the project report. However, project 
plans could be entered in the system with no control and 
reporting requirements or there could be a complete absence of 
such plans. The minimum requirement in IPAD will be that the 
subtask must be defined before it is activated so that resource 
accounting and reporting can be done by the system. 


5,3 USSR INTERFACE 


5. 3. 1 Per sona l Terminal 

The primary interface between the user and IPAD will be a 
"personal terminal". a "personal terminal" is uniquely 
associated with a given user while be is active. Each user will 
be identified to the system via his identification code. Since 
the IPAD system will not have terminal handling software, the 
user*s first contact will be with the operating system. If IPAD 
is the only system requiring terminal support, the operating 
system will be a transparent message carrier. 


5.3.2 com mand Flo w 

In general, each command to IPAD will be mapped into one or 
more operating system commands. Control will then be given to 
the operating system. Shen the operating system has completed 
a set of commands, IPAD will be recalled to determine if all 
commands have been processed. If not, the above process will be 
repeated- When all commands have been processed, appropriate 
entries will be made in the subtask records and all- library 
entries will be disposed of as requested by the user. An 
activity in progress may be interrupted and another activity 
initiated. Upon completion of the second activity the user may 
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continue the first activity, This sequence may be nested. The 
execution sequences for data and programs may be stored as job 
descriptions in the IPAD libraries. The general flow of control 
for IPAD and system commands is shown in figure 5.4. 

While many languages may exist within the total IPAD 
domain, the IPAD executive itself needs a relatively limited 
language capability. The basic commands are modal statements, 
i.e,, the command indicates the basic intent of the user. These 
commands are the means of executing all application modules, 
executive utility functions and data base management functions. 
Recommended basic commands were given in section 3.2. 


5.3.3 Sign-On To IPA D 

The sign-on procedure initiates a new subtask or restarts 
an existing one. A user must supply an identification number 
(DID) and security passwords. Sign-on will allow the user 
access to all library entries where his ID number appears in the 
permission code tables. If no subtask name is input, a new 
subtask, will be assumed and IPAD will ask for a subtask plan 
identifier so that planning data can be examined to find the 
appropriate subtask name. Planning data can also be used to 
search for subtasks in progress. 

If an existing subtask name is given there will be a 
library entry of that name in the community library, and the 
subtask library will be established using the information in the 
entry. Except for records involving fime, the library contents 
for existing subtasks will be as if the user had never signed 
off, providing continuity across time lapses in activity. 

If a new subtask as defined, the following information must 
be supplied by the user or through system defaults: 

a) Dser validation information for the particular 
project. 

b) Basic options such as display formats, etc. 


5. 3. 4 C om m unicati o n With IPAD 

Having signed on, the user may initiate any of the IPAD 
basic commands in his command permission profile. The system 
will respond in one of three basic modes. 

/ 

a) Monologue - The user knows the command format and is 
capable of delivering complete commands to IPAD. 
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Figure 5.4- IPAD System Command Flow 


b) Dialogue - The user knows the general workings of IPAD 
but is not capable of entering complete commands. 

c) Teach - The user may, at any time, request assistance 
and IPAD will go into a partial or full teaching mode 
depending on the request type. 


When 

following 


a user’s response to the system 
possibilities exist: 


is 


interpreted. 


the 


a) Execution is possible and: 

o The command is correct in form and intent; or, 

o The command is correct in form but the user’s 

intent is different from the potential execution 
results. 
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b) Execution is not possible because: 

o IPAD understands the command but has insufficient 
information, or 

o IPAD understands . the basic command type, but 
detects an error in format, consistency, etc. ; or 
o IPAD does not understand the command. 

These responses are summarized in the following table and will 
be built into the system. The number indicates sequence of 
action, and parentheses indicate optional actions. 


EXECUTION OF 
COMMAND 

RESPONSES 

Do It 

Ask If They 
Understand Action 

Ask If They 
Would Like Help 


•Possible 

(2) 1 

(1) 



Not Possible 





- Unable 


(3) 

(2) 

1 

- Detectable Error 


(2) 

(3) 

1 

- Unrecogn izabl e 



2 

1 
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5.3.5 Sign-Off From IP&D 


Sign-off has two basic modes - inactive or terminated. If 
inactive, the system will save the contents of the subtask 
library in the community library and prevent purging or editing 
of those versions of community library entries associated with 
the subtask. If the subtask is terminated, disposition 
instructions for all items in the subtask library must be given. 
Sign-off is a discontinuation of activity on a particular 
subtask and may or may not terminate the activity period. 


5, 3. 6 Batch A cc e ss 

IPAD commands are available in batch mode and must be 
submitted in monologue fashion. Sign-on and sign-off will be 
similar to interactive mode, including the subtask concept so 
that continuity is preserved. The end of a batch run is similar 
to sign-off with subtask inactive, A user may submit a job 
through batch and, regardless of the results, make his next 
access either from batch or from the terminal. Thus, the IPAD 
system will leave an interrupted subtask in the same state for 
batch as for interactive access. 


5,4 LIBHAHIES 

When active on any given subtask, an IPAD user's data base 
is his subtask library and that portion of the community library 
to which he has access. Any new information must come through 
his subtask library or from access to additional community 
library information. In these two libraries, the user is 
concerned with library entries and variables and the dictionary 
which holds their definitions. 


5.4.1 Library Entries (LE) 

The primary unit of information storage in an IPAD library 
is the library entry. In order to handle the wide variety of 
information expected in the IPAD data base, many different types 
of library entries have been defined. The most significant 
distinction among types is between user and system entries. 
User entries are composed of alphanumeric information which is 
either input to or output from some operational module in IPAD. 
This entry type is composed of one or more library variables 
(see section 5.4.2). A system type does not contain library 
variables. These entries contain source code, binary code, 
project plans, etc. The set of library entry types is 
expandable. 
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5.4.2 Library Variables (LV) 


A library variable is defined in an IPAD dictionary (see 
section 5,4.3) in terms of its technical significance. This 
includes both its engineering meaning and its oatheiaatical 
meaning (e.g.^ single real number, rectangular matrix, complex 
vector, etc.). The isolation of variables is a mechanism for 
organizing information transfer between technical code and 
between people. A library variable may be resident wholly 
within more than one library entry, but a multiple valued 
variable (e.g., a vector) may not be partially resident in 
several library entries. Any variable may have any number of 
values residing in separate library entries, but there will only 
be one definition of that variable in any one dictionary. 


5.4.3 Library Dictionaries 

Each library in the data base has at least one dictionary. 
Typically one would expect a subtask library to have only one 
dictionary, but there may be several dictionaries in the 
community library. When library entries or variables are 
referenced, a specific dictionary will be used to reconcile 
potential ambiguities. Generally the context of the reference 
will be sufficient to define the situation; e.g., the user’s 
subtask library is assumed to contain any item referenced, and 
if it cannot be found, a specified community library dictionary 
will be used. 


5.4.4 L ib rar y Entry Nam in g Conventi ons 

The user will reference library entries by a generic name , 
assigned by the entry originator. Some library entries <e.g., 
data sets and coding modules) will be modified during use and 
will therefore require version numbers. In addition, the source 
of data sets generated during the course of work will be 
identified. Hence, qualifiers will be appended to the entry 
name recording the names of data sets and application modules 
used to generate the data set. Therefore, library entry names 
will have the form 

NAHE. VERSION (QUALIFIER) 

To access a library entry, the user, through direct command or 
through job control, will give enough of the library entry name 
to uniquely identify the entry- Less than that will cause the 
system to request more information. 
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Haa e - The name is any set of characters supplied by the user. 
When stored in the directory, the owners ID and password and the 
subtask identification will be appended to the name by IPAD. 

Versio n - Version is both a user and IPAD generated item. IPAD 
will require a change in version number whenever modifications 
are made to a library entry without changing the name. The 
system will provide the capability of referencing the "latest 
version". 

Qual i fie rs 

The basic intent of qualifiers is to insure documentation 
of the origin of library entries. Both the user and IPAD 
establish qualifiers. When the user initially creates a library 
entry, he supplies a qualified name, except tor those entry 
types which logically do not require qualifiers. As the entry 
is used for various jobs, its qualifier is used by IPAD to 
establish qualifiers for newly qenerated entries. The qualifier 
is associated with a library entry and not individual library 
variables within the library entry. 

Figure 5.5 illustrates how qualifiers are generated during 
the execution ot a job- The elements in figure 5-5 are defined 
as; 


Job Components 
Input Library Entries 
Intermediate Library Entires 
Output Library Entries 


X, Y, Z 
A, B, C, F 
D, E 

L, M, G, 


If B is a library entry qualified by Q, it is 
identified as B (Q) -where Q is either supplied by the user 
or is a qualifier generated by IPAD as a result of a 
previous execution. The qualifier generated for L in 
figure 5.5 at job assembly time will be 


L(Z(D(X(A(NULL))) ,E(Y(B(NULL) , C (NULL) )) ,F (NULL) )) . 


33 



L M G 



Figure 5.5 Sample Job Organization 


The qualifier generated for G at job assembly time will be 
G (Y{B(NOLL) ,C(NULL) ) ) . 

The, user will normally not deal with the long form of the 
fully developed qualifier, he will, in general, use only 
enough of the name to insure an unambiguous reference. 

The null qualifiers are supplied at execution time 
to complete the qualification of the output library entries 
for each specific job execution. 
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5.5 THE JOB CONCEPT 


Operational modules and utility functions are executed as 
one or more jobs. A job is a selected set of operational 
modules (Oti) and/or other jobs organized by a user as part of a 
subtask. An OM consists of a selected set of subroutines 
organized as coding modules (CM) to execute in a sequence as 
defined in a "main program". Hithout regard to execution 
.sequence, the above relationships are shown in figure 5-6. Any 
set of source code used in several OM's should be entered as a 
CM to m.ake it more visible to the user community. The same rule 
applies in the OM to job relationship. 



Figure 5.6 Sequence of Job Definition 
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Figure 5.7 Steps in Job Construction 


5.5.1 Enter ing Co d ing Mo d ules 

Source code and descriptions are entered as Coding Modules 
as shown on figure 5.7. 


5.5.2 E uildinq Opera t ional Modules 

A complete oa must have one main program, i.e., only one 
main program may exist in the CM*s. being packaged into an OW. 
If -a main program does not exist in a CH, one must be written as 
part of the OH building process. Library entry information, as 
shown on figure 5-7 must be defined at OH build time. Any files 
used by the OH and not linked to library entries by the CH*s 
must be linked at this time. If an OH is placed in the 


36 





















community library, all its component CM*s must Jae in the 
community library also. 


5.5.3 Constructing J obs 

Constructing a job is similar to building an OM. fin 
execution sequence with optional logic at OH boundaries is 
specified. The executable units in a job are OM's and other 
jobs. During job assembly the qualifiers for all output library 
entries will be partially constructed. Information supplied at 
job execution time will complete the qualifier. Job 
construction is illustrated in figure 5.7. 


5.5.4 E xec u ti on of Jobs 

When job execution is requested-, the subtasfc library and 
community library are searched for the correctly qualified input 
library entries. The library entries for all intermediate and 
output library entries are set up in the subtask library and are 
qualified by both the set of qualifiers generated during job 
construction and the set received with the request for 
execution. All file linkages (as specified in the job 
definition) ace set. Activity record information for this job 
request is written and commands are delivered to the operating 
system for execution. 


5.6 DATA BASE HAKAGEMENT 

The libraries contain two categories of information 

structures; system defined and user defined. No formal 

distinction is made between these categories by the data 
manager, but system structures are not generally accessed 

directly by operational modules. The system structures are used 
to store operational modules, referencing information, control 
information, etc. User structures contain data • produced and 
manipulated by application modules- Figure 5.8 gives a general 
description of the data base contents. 

The user is not restricted to a fixed set of data 

structures. The two basic modes of access to data by 

application modules are: 

a) Explicit T/0 - The user's code is written with 

detailed knowledge of the data structure of the 
library entry. 

b) ■ Implicit I/O - The user's code references variables 

within a library entry by name, letting IPAD do all 
storage and retrieval. 
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Kith explicit I/O, library entries are made available at 
execution time by the data manager. The data manager then 
assumes that the user's code will handle all read/write 
operations. 

With implicit I/O, the operational module definition 
contains declarations naming stored data definitions, and 
explicit I/O ‘Statements are replaced by commands to the data 
manager to fetch and store data. The data manager carries out 
the required I/O as specified by the appropriate stored data 
definition. A schematic of the two I/O modes is given in figure 
5.9 with a table of comparisons in figure 5-10. An example is 
given in figure 5.11. 


STORED DATA DEFINITIONS 
DIRECTORIES 


IPAD SYSTEM 
DATA STRUCTURES 


LIBRARIES 

DICTIONARIES 


DATA SETS 


JOBS 


USER DEFINED 
DATA STRUCTURES 


USER DATA 


• The Number and Varlely of User Data Structures Is Indeterminate. 

• DMS Uses Stor«l Data Definitions to Carryout Actions Which Will Satisfy 

User's intent t 

• Physical Addition / Modification / Deletion of Data 
9 Logical Unking / Delinking of Data 
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Figure 5.9 Relationships of implicit and Explicit 1/0 to the Data Base 


Stored Bata Def i ni ti on ( SDD ) - All information in the IPAD 

libraries may be accessed through a stored data definition {see 
figure 5.12). SDDs for user data are user supplied, avoiding 
the problem of forcing users to change their data formats and 
structures to conform to a single standard. 

Each library entry in IPAD may have one or more formats 
associated with it. When described fay a single SDD, multiple 
formats imply the use of subsets of the whole library entry or 
possibly different unit conversions. Multiple format SDDs also 
allow external formats (e.g. punched cards) to be -described. 
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SDDs are mandatory when using implicit I/O and optional for 
library entry used in explicit I/O only. 

I mplicit I/O - SDDs require each variable to have a definition 
in the variable dictionary and a corresponding global name. The 
utilization of global names in the SDD eliminates many of the 
ambiguities that could arise when different users are 
interpreting data variables or when decisions are made regarding 
the selection of a coding module for a specific computation. 
The 3DD also permits variables to be given local names for 
different subroutines. During execution, calls on the data 
manager will result in data being moved from the storage media 
to the user's working area. Data will be positioned in the 
user's working area so that local name references to variables 
in the user's code will be correct. 


EXPLICIT I/O 

IMPLICIT I/O 

• DMS Connects OM to an Entire Data Set 

• DMS Connects User to All or Part 
of Specified Data Sets 

• 0/Vl Performs all 1/0 Operations 
Without IPAD Intervention 

• User Requests Data 

• By Library Variable (Data Item Key) 

• By Position 

• Sequential Data Sets 

• Logical Chains 

• DMS Functions Performed only on 
Entire Data Set 

• DMS Functions Performed on individual 
Library Variables Within Data Sets 




Figure 5.10 Attributes of Explicit and Implicit i/0 
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Pre-Existing lor Independent) Code May Require Data Input In a Certain Structure 

• If Data Exists In Proper Form, DMS Connects Data to Program 

• If Data Exists, But Not In Proper Form, a Pre-Processing OM Using SDD's 
Can be Used to Interface Pre-Existing Code Without Changes to the Code 


DATA BASE 


PROCESSING 



Figure 5.11 Example of Explicit and Implicit I/O Operations 


Expli c it I/O - When the data handling logic is explicitly 
present in the source code, (as it is with all source code 
generated without data manager type functions available) the 
data manager's function is limited to module boundaries; i, e. , 
the data manager will prepare the data linkage prior to 
execution and dispose of the data after execution. Knowledge of 
the library entry internal structure by the data manager is not 
required during program execution. 


5.7 PBIVfiCY, SECURITY, COHTROL, INTEGRITY 

Kany of the design features of IPRD, such as the library 
facility, in themselves provide privacy, security, control, and 
integrity. Other features are specifically designed to support 
these requirements. All features supporting these requirements 
are described in tne following paragraphs. 

Subt ask and Communit y L ibrari es - The community library contains 
all of the application modules and data generally available to the 


f*OOE QDALIT5!; 
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• AN SDD DESCRIBES A DATA STRUCTURE WHICH IS USER'S IVIOOa 

OF REAL WORLD 

• AN SDD FILED IN THE DATA BASE IS A TEMPLATE USED BY DMS WHEN 

ACCESSING DATA 



An IPAD Data Set 
May Have More ■ 
Than 1 Structure 



Figure 5.12 Stored Data Definition illustration 


community of users as a whole. The subtask library contains 
elements of the community library, and provides space for the 
user to do scratch work and otherwise prepare or generate data 
for entry into the community library. The subtask library may 
contain entries peculiar to an individual user and not available 
to the community at large. In this case, provisions are 
reguired to preserve the integrity or protect the guality of 
information being transfered to the community library. 

Cont roll ed Acc e ss to IPAD Eata - Access will be controlled 

through access codes associated with individual entries of 
application code and data. for example all users could be 
allowed read permission for a data set but only particular- users 
could be allowed write permission. 
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There wil.l be at least five types of library entry access 
codes: read, write, extend, purge, and execute. Head access 
implies permission to read only. Write access implies 
permission to change existing information to a library text 
entry with corresponding changes in the library directory entry. 
Purge access implies permission to eliminate the entire library 
entry. Ex ecute access implies that the entry may be executed 
but cannot be read for any other purpose. 

The list of permission codes (i.e,, identifiers for each 
user permitted each type of access) for each library entry will 
be listed in tae acce.ss part of the directory. Each user's 
identification (HID) will be checked against these to determine 
the allowable access permission. 

The above discussion relates only to the community library. 
Items originating in the subtask library are assumed to have all 
levels of access to the subtask owner. In the event the user 
requests write access to a community library entry for which he 
only has read permission, items may be copied to the subtask 
library in order to allow the task to continue without causing 
undesirable community library changes. 

Controlled Access to IPAD Sys tem Co mm ands - Use of IPAD system 
commands (see section 3.2) will be controlled through permission 
codes. A new user entering the system will be assigned a 
command profile internally within the system. This profile will 
define command and data regions the user may access. For 
example, except for exceptional circumstances, every user will 
be allowed to purge information from his subtask library but 
only specific users will be allowed to purge information from 
the community library. Specific permission will be required to 
send data outside IPAD. Transfer of information from a subtask 
library to the community library may be controlled to allow 
review before permitting the transfer. In tight security 
situations, purge permission from particular subtask libraries 
may be denied. 

Uniq uene ss of Ve rsions - Since IPAD is designed for large groups 
of users working on the same or related projects, it is 
necessary that they be able to change data sets and application 
modules without destroying the work or disrupting the plans of 
other users. Hence, any alteration of application modules or 
data within the community library will result in a new version- 
The root version will remain intact unless specifically purged 
by a user having permission- The assignment of new versions 
will be automatically required by the IPAD system whenever 
modifications are made. 
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T race o f Antecede nts - A trace of the data sets and application 

modules'"used to~qenerate a new data set will be compiled and 
preserved as qualifiers in the data set identification. This 
will allow users to trace the generation of a library entry. 

Trace of Data or_Codg L ea v ing IPAD Consol - A trace of data or 
code either purged from IPAD libraries or sent to a location 
outside IPAD control is required to protect the proprietary 
interests of the owner ana to protect against sabotage, spying, 
maliciousness, or accidents. 

P ersonal Us er I d en tific ation - Entry to IPAD will be via a 
personal user identification code to allow individual assignment 
of responsibility for certain acts and assignment of permission 
and access codes. 

Rel iability an d Q u al i ty C ontrols - where possible, the system 
should require conformity ho standards and procedures that have 
been developed to ensure the reliability and quality of the 
system code, data and application modules. Further, a means of 
rating the reliability of new application modules should be 
provided according to the degree of checking that has been 
completed. 

Protecti o n Again st Self-Inflicted Accident s- Protection against 
self-inflicted accidents will be made through the structure of 
the command language and by provision for recovery from command 
error where the action being taken has nonreversible 
consequences. 

Se cu r ity o f the IP AQ System Code - Where possible, provision 
will be made to control access to the IPAD system code itself to 
prevent tampering or unauthorized extensions. 

Security of the Security F e atures The m selves - Careful 

consideration is necessary to restrict access to permission and 
access codes only to those persons authorized by the library 
owners . 

Controlled R elatio nship Be tween Subtasks Withi n Pr ojects - An 

important feature of the IPAD system will be the ability to 
input project planning as data by which lower level work can be 
monitored and regulated. Hence, a user responsible for a 
subtask may be informed of the relationship of his subtask to 
other subtasks forming the project. 

Government or defense security provisions are provided by 
law or by requirement from the specific agency involved and are 
not considered here. Likewise, special security provisions 
necessary for a company to protect proprietary material are not 
considered. 
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6.0 TECHNICAL DESIGN SPECIFICATIONS 


6.1 SYSTEM DESIGN METHODOLOGY 

Structure! Programming is a formal work dealing with 
software engineering and hardware-software system design and 
development (ref, 1, 2, and 3) . The objective of this work is 
to transform the development of computer systems from a seat-of- 
ths-pants art, to a disciplined technology. This approach has 
been utilized to develop the IPAD system design. 

The structured programming approach is a top down design 
method in which the design proceeds from the general to the 
specific. Bach refinement is a level in the system design. 
Tree structure diagrams give the system functional components in 
levels of increasing detail. The nodes at any one level in the 
tree structure are states of activity for the system. The 
entire system is included in the total set of nodes at each 
level, and in fact, higher level nodes are summaries of lower 
level nodes. 

Transition diagrams describe how the system components, at 
each level, are functionally related. The diagrams also specify 
the conditions under which there will be a transition or state 
change within a node or from one node in the tree to another 
node at the same level. These transition conditions are (1) the 
input data or conditions that trigger the transition and (2) the 
output data or results existent in the system at the time the 
transition is made. Figure 6.1 is a sample tree structure and 
transition diagrams for a three level system. 

The IPAD system design given in section 6.2 and Appendix A 
follows the general form described above. For level 1, twenty- 
nine nodes or states are described. Except for those level 1 
states dealing with hardware or host operating system protocol, 
the level 1 states are each refined into level 2 states- The 
level 2 states are, in turn, broken out into level 3 states, and 
so on. The emphasis in the design was placed upon consistency 
in detail rather than consistency in levels documented. Hence, 
there are differences in the depth or number of levels reached 
in some of the tree branches. 

While the design is presented in top down form, the actual 
design process does not proceed monotonically. Generally, 
design at level n will result in a review of some elements of 
the design at level n-1, n-2, etc. The advantage of the method 
is that the examination of effects is an orderly process and the 
consequences of the iterative design process are highly visible. 
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TREE STRUCTURE DIAGRAM 


A.A.B 


A.A.C A.B.A 


TRANSITION DIAGRAMS 


( input/conditions, 

output/ results ) A.B 



( input/conditions, 
output/results ) 


A. A. A 


%••««««• •I 

Va*V*!/ 


( i/c, o/r ) 


A.A.C 


T i/c, o/r ) ® 


{ i/c, o/r ) A.B.A 




A.A.B 


( i/c, o/r ) 


A.B.B 


Figure 6.1 Structured Programming Diagrams 




Level 1 nodes are included in section 6.2. Level 1 and all 
lower level nodes are included in appendix a. appendix a is 
divided by level; i.e., all information is given for level 1, 
then for level 2, and so forth, level 1 in section 6.2 and each 
level in appendix a contains the following diagrams and tables: 

State D esc r ipt io n Tab les--Three pieces of information are given 

for each node. 

a) Short Structured Name — This name consists of a set of 
one or two alphabetic characters catenated in the 
form : 

rs 

rs. tu 
rs. tu-. rw 
etc. 

The syllable position denotes a level. . For example, 
if node a is at level 1 then node a.B would be at 
level 2 and would be a state of node a. Hence, the 
tree diagram can be formed from the short structured 
names. There is no requirement that these names be in 
sequence, i.s., the existence of node a.B and node a. D 
does, not presuppose the existence of node A.C. 

b) Long Name — This name is descriptive of the function of 
the node. For example, node E has the long name 
"Subtask Set-Up.” 

c) Description — Several sentences describing the 

capabilities of the node. 

allowed Tra nsition tables — This is a tabular representation of 

the connections between nodes that have a common parent at the 
next higher level. The states from which transitions are made, 
along with the corresponding references to the input/condition 
and output /result tables, which follow, are given. A bent arrow 
is used to flag entry and exit points from the parent node. 
When exits are shown, the level of the state exited to may be at 
a higher level than the state being exited from, depending upon 
the level of tree structuring completed. 

Trans it io n Di ag ra ms — These are a graphical representation of the 
Allowed Transition T’ables. They can be constructed -from the 
transition tables and are valuable for visualizing 
relationships. 

In pat / Co nd itions L is t Ta bles — This is a list of the input or 

conditions that trigger a transition or change of state. This 
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list should be used in conjunction with the Allowed Transition 
tables. 

Out p u't/Res ul t List Ta bles--This is a list of the output or 
results that are , existent in the state when a transition is 
made. This list should also be used in conjunction with the 
Allowed Transition tables. 

Tree diagrams are not included. They can be constructed 
from the structured names. 

Abbreviations are not used in level 1. They are used in 
lower levels to facilitate writing. Definitions of 
abbreviations are given in section 4.0. The text part of 
section 6.2 and Appendix A was created by a computer program 
from data supplied by the system designers. This computer 
program checked to ensure that transitions were made between 
valid states and that lower level states were correctly 
referenced to higher level states. 


6.2 SYSTEM DESIGN SPECIFICATIONS 

Figures 6.2 and 6.3 are the level 1 transition diagram. 
Node F is repeated on figure 6.3 for reference. These figures 
should be read in conjunction with the State Descriptions, 
Allowed Transitions, Tnput/Condition List and Output/Sesult List 
following the diagram. In some cases, the nodes at level 1 are 
more generalized functions than those given in Volume-ITI and in 
section 3.2 of this document. The association is given in table 
6 . 1 . 
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FOI/DOUT PRAMET 

/ 


FBAMg 



* si« 


TERMtNAL DIALOGUE WITHOUT 
A CHANGE OF STATE 


Figure 6.2 IPAD System Design Level 
Trans it ion Diagram 
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ORlfelNAK PAGS'lS 

CO.'IPONENTS OF IPAD LEJEL ONE POOR QUALITYl 


STATE 

A 

p 

C 

0 

r 


STATE OESCRI^TIONS ***** 

LONS NAM?. AND TEXT 

PERSONAL ^E^MINAL OFF 
THE EOUIPNENT i3 NOT ACTIVE. 


PERSONAL terminal ON 

THE £AUI="hSENT IE ACTIVE dUT NO DATA PATm TJ THE 
CO-tPUTER EXISTS. THE fc JJIPMEnT IS A PEKSONAu TERMINm., 
NOT A RL-'--.DTE JOJ ENTRY TERMINAL, BUT NAY JE AUG'IEnTcJ 
v^ITh peripheral 0EVISF5 EUDri AS CASSETTE TAPE , PRINT tE , 
PLmER. 


PERSONmL terminal CONNllTEv 
THERE NOW EaISTS A TWO-WYY UATA PATH BETWEEN THE 

terminal anu the computer 


CPERATihC SYSTEM COMMAND 1CGE 

THE UStiR IS NOW AHlE TU ENTER COMMANDS TO THE TIME 
SHARING SYSTEM IN THE HOST OPERATING cYSTEM 


SU'JTASK SET-jP 

THE USER IS MOW IN COHMUMICATION wITH IPAL AND HE 
IS lITHER initiating a iEr, SUSTASK OR CONTINJiMo AN 
OLD ONE. IN EITHCK CASE, T.Hn NET RESULT WILL 3E Tml 
establish 1ENT OF HIS ACTIV'c SUGTASK uIORARY. 


SJdTASK CJi''IMAND fiGDE 


THE USER IS NOW ABLE TO ISSUE IPAD CASIC COMMANDS 
TO ADVANCE HIS SUBTA3K WORK. 
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IPAb, ilHVEL-. OMt 
{COMTlNUcQ) 


STATE 

G 

H 

I 


K 


***** STATE DESCRIPTIONS .(CONTINUED) ***** 

long name and TjiXT 


LEARNING A-jCOT IPAO 


THE ACTH/ITY OF GAINu.Nb INFORMATION ABOUT IPAB 
EITHER AS A TAUGHT COURSE (JR AS HELP NlTH A SINGLE 
CO-IMAMD D.R MOuU.E. 


SEARCHil'lG ThROUGH THE uioRARIES 

THE PiOCcSS OF SCaNNIMG UIGTIONARIES AND uIREGT- 
ORIES TO IJENTIFY ANJ LOCATE INFORMAT lO.N IN THE IPAJ 
DATA BASE. 


C^EAFINO l-IciRARY ENTRIES 

THE PROCESS OF INSERTING DaTA (NUMERICAL ANO OTH- 
Ek) into the IPAD DATA 3ASE xESULTINO IN NEN LlJRARY 
ENTRIES(LE). INCluDEO is THE ENTERING uF SCURCf- CODE 
FOR CODING MOOUlES(CM) , INFORMATION FOR STORED DATA JiF- 
'i-NI-TI0NSC3 DOT-rh'JS-TANCES aF“iJA*T'A- -S-ETS-(-DS-)-T-OrSPtA-f-- M E-'ldS 
(01), AND THE INSTANCE JK THE SYSTEM DATA SET CONTAII- 
INi ACCESS AND PERMISSI JN CODES. 


MOjIFYli'jG lIlRARY ENTRIES 

ALTERING CURRENTLY RLSIOENT LidRARY ENTRIES. THIS 
CAN INVCLV:l G-iA)G£S TO AMY (/MlIu- IPAD LIBRARY ENTRY 
TYPE. 


CONSTRUCTING A JOd 

ARRANGING AVAIlmDLE CODING MUDULtS(CM) INTO OP-'i- 
ATIONAL HO JULES (OM), OPERATICIAl MODULES INTO JODS, AND 
OPERATIONAL MODULES mNO PREVIOUSLY GEFiNEO JOGS INTO 
NEW JObS. 
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ORIGINAL PAGE 
OP POOR QUALITY 

IPAD LEVEL ONE 
(CONTINUED) 


♦ ♦♦♦V STATE DEiGt<IPTIO.J':i (CONTINUED) 

STATE LCNj name AnJ TEXT 

N EXE&UTIN& A JOi- 

ACTIVATING A PTEVlOUSLf CONSTROCTEO JOO 

0 GOHMUNiCAriNo WITH A JGb 

bEING INTtiACTIVL "iiTH A USEk COnS ThUCTEO JjT 

F DISPLAY I M.i RESULTS 

SCANNING, checking, a lO iNTnRRObATi Nb INFCRNA TION 
COJTMiNtO IN lIHRARY ENT'.IEb JF ANY TYPE. 

Q OISPCilTiJN OF 1-16RARY ENTRIES 

TRAHSFEkRI ' iG LijRARf ENTRIES dETWEE') IPAO Ll-^- 
RARILS, SENDING ITENi OJTSiJE OF I PAD ( OFFLINE , OK VIA A 
CO 1HUNIOA nON NETWORK.), ANO KcHOVAu OF JTWANTEL Llb<A.RY 

entries from the data DASE. 

T SUbTAiK STr.r CO'iTRuLLED A SORT 

THE TERMINATION OF THE CURRENTLY inERRUPTEO SUi- 
TA3K STEP. 

U SJ3TASK I 'JTt.R<U^TICN 

ACTION AIHED AT TE i^ORARY INTERRUPTION OF THE SUG- 
task ACTIVITIES WIT.H THE ImTENT OF Rl-STARTInG AT A 
LATER Tlrtt AT THE PRECISE POINT OF I NTF.RRUPTI OR, 
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IPAD LEVEL ONE 
(CONTINUED) 


STATE 

V 

W 

GA 

HA 

lA 

KA 

MA 

NA 


♦ STATE DESCRIPTIONS {CONTINUED) *****' 


LONG NAhE AND TEXT 


SU6TAS< TERMINATION 

THE JSER HAS COMP:.ETEJ THE DEFINED SUBTASK AND 
NON DESIRES TO DISPOSE JF ALL REMAINING INFORMATION, 

LOG THE TERMINATION IN THE PkOJEGT PL«N3, AND ISSUE ANY 
REOUIREO REPORTS. 


DEFINIi'iG LifRARY ENTRIES OR WARIADLES 

A DEFINlTrON IS A DICTIONARY ENTkT hHIGH CONTAINS 
THE MEANING OF A VARIABLE OR A LIBRARY ENTRY AMO GROSS 
REFERENCING INFORMATION. ALL COMMUNITY LIBRARY tNTRIES 
AND variables REFERENCED IN DATA SETS REQUIRE DEFIN- 
ITIONS. DICTIONARY ENTRIES ARE OPTIONAL FOR SUbTASK 
LIBRARY ENTRIES. 


lf4TERRUPTED LEARNING ABOUT IPAD 

■ " TFrS~TS the STATE rNMETTrATELf FOLLOwrNb“S 

PAUSE DURING LEARNli4G ABOUT IPAQ. EACH OF THE STATES 

G, H, I, <, M, 'i, 0, p, a, AND h Have a similarly 
ASSOCIATED STATE. 


INTERRUPTED 

INTERRUPTED 

INTERRUPTED 

INTERRUPTED 

INTERRUPTED 


SEARCHING THROUGH Llfc’RARIES 
CREATING LIBRA-i-T ENTRIES 
MODIFYING LIBRARY ENTRIES 
CONSTRUCTING A JOB 
EXECUTING A J03 
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IPAO LEVEL ONE 
(CONTINUED) 


ORIGINAL PAGE IS 
OE POOR QUALITY 


****^ STATE DESCRIPTIONS (CONTINUED) 

STATE long N'AHE AND TEXT 

OA interrjpted oohhuni ca t inu with a job 

PA INTERRJPTEO jlSPLATING RESULTS 

GA INTEKRJPTEO jlSPUSITION OF lURART ENTR. 

WA INTERRUPTED OEhlNlNG LldRART ENTRY/VAR 
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IPAD LEVEL ONE 
<CONTINUED) 




AL-OWEO TRANSITIONS ****‘>- . 


FROM 

STATE 

TO STATE 

INPUT / 

OUTPUT 

(i» = 

ENTRV) 

(f = EXIT) 

GONuITlON 

RESULT 

.♦A 


d 

1 

1 

B 


A 

14 

14 



r* 

O 

• 3 

2 

C 


A 

14 

13 



B 

IS 

15 



0 

T 

3 

0 


A 

14 

13 



L> 

13 

13 



d 

15 

15 



o 

12 

12 



L 

4 

4 

E 


A 

14 

2C 



B 

13 

16 



F 

5 

p 



F 

6 

& 



V 

16 

6 

F 


A 

14 

17 



3 

13 

17 



0 

17 

22 



G 

34 

35 



H 

lo 

22 



H 

34 

35 



I 

id 

22 



I 

34 

39 



K 

21 

22 • 



.< 

34 

39 




23 

22 



lA 

34 

39 



H 

24 

22 



N 

34 
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0 

34 

39 



F 

27 

22 



P 

34 

39 



a 

2d 

22 



a 

34 

39 



T 

s 

9 



u 

3 

G 



M 

7 

7 



N 

2 u 

22 



w 

34 

39 
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ORIGINAL PAGE IS 
OE PCX)B QUALITY! 


IPAD LEVEL ONE 
(CONTINUED) 


****^ ALLJNED TRAnSITIJNS (CONTINUED) 


FROR STATt 

TO STATE 

INPUT / 

OUTPUT / 

It* = ENTRY) 

(,♦ = EXIT) ■ 

condition 

result 

G 

A 

M 

lA 

4 0 


3 

13 

4C 


F 

35 

42 


GA 

51 

5 6 

H 

A 

14 

4C- 


a 

13 

4-: 


F 

35 

42 


HA 

51 

0 Li 

I 

A 

14 

4C 


B 

13 

40 


F 

35 

42 


lA 

31 

36 

K, 

A 

14 

4G 


f> 

13 

4 L 


F 

35 

42 


<A 

31 

56 

M 

A 

1*+ 

4C 


8 

13 

4C 


F 

35 

42 


HA 

31 

36 

N 

A 

14 

4C 

■ 

a 

13 

4C 


F 

35 

h2 


0 

25 

22 


NA 

31 

36 

u 

A 

14 

4D 


'3 

13 

4 L 


F 

35 

42 


N 

26 

22 


OA 

31 

36 

P 

A 

14 

4L 


0 

13 

4C 


F 

35 

42 


PA 

31 

36 

a 

A 

14 

4C 


8 

13 

4C 


F 

55 

42 


UA 

31 

36 

T 

A 

14 

it 


B 

13 

i c 
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IPAO LEVEL ONE 
(CONTINUED) 


♦ /^LwONEL) transitions (CONTINUED) 


FROM STATE 

TO STATE 

INPUT / 

OUTF-“JT 

(f» = ENTRY) 

= EXIT) 

CONDITION 

result 

U 

A 

lA 

19 


3 

15 

19 


D 

li . 

11 


E 

10 

ic 

V 

A 

14 

21 


B 

13 

21 


D 

11 

11 


E 

13 

le 

W 

A 

14 

4C 


jU 

13 

4C 


F 

35 

4-2 


HA 

31 

36 

6A 

A 

14 

4C 


o 

13 

41 


F 

33 

3 o 


O 

38 

37 

HA 

A 

!«+ 

4-: 


0 

13 

41 


F 

33 

3c 


H 

32 

37 

lA 

A 

14 

4l 


B 

13 

41 


F 

33 

3c 

_ 

I 

32 

37 

K'A 

A 

14 

42 


B 

13 

41 


F 

33 

3& 


K 

32 

37 

MA 

A 

14 

4t 


3 

13 

41 


F 

33 

3 o 


M 

32 

37 

NA 

A 

1-4 

J+C 

■ 

8 

13 

41 


F 

33 

38 


N 

32 

37 

OA 

A 

14 

40 


3 

13 

41 


F 

33 

38 


0 

32 

37 
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IPAD LEVEL ONE 
(CONTINUED) 


♦♦♦4* ALLOWED 

TRANSITIONS 

(CONTINUED) 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(«♦ = ENTRY) 

(r* = EXIT) ■ 

CONDITION 

' RESULT 

PA 

A 

14 

4l 


a 

13 

41 


'F 

33 

38 


P 

32 

37 

OA 

A 

14 

4G 


8 

13 

. 41 


F 

33 

3 b 


a 

32 

37 

W A 

A 

1*+ 

4C 


d 

13 

41 


F 

33 

3 b 


w 

32 

37 
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OIUOINAL PAGE5 19 

IPAD LEVEL ONE QDAUTa 

(CONTINUED) 


Input / condition list 


NUM3ER TEXT 

1 SWITCH TU^NEO ON 

2 DIAL UP 

S VALID OS LOG ON INFORMATION IN THE PROPER SEQUENCE 

4 VALID OS OOMMANJ TO LxEOUTE IPAD 

5 VALID SUbTASK IDENTIFIER FDR A NON EXISTING SUDTASK 

6 VALID SUBTASK IDENTIFIER FOR AH EXISTING SuOTASK 

7 TERMINATE 

3 QUIT 

9 STOP 

ij Another 

11 DOv»E 

12 • hello 

13 USER HANGS UP 

lA SWITCH TJRHEO OFF 

15 3VE 

ib SUDTASK RECORDS SHOWING AN INTERRUPT OCCURRED DURING 
THE SUB TASK TERMINATION 
17 HELP 

13 SEARCH 

19 CREATE 

21 DEFINE 

21 MODIFY 

23 CONSTRUCT 

24 EXECUTE 

25 CONDITION CODE SHCWlwG TERMINAL INPUT IS RtOUIkED 

26 LAST LINE OF USER INPUT 

27 DISPLAY 

23 DISPOSE 

31 PAUSE 

32 GC 

33 ANY COHHANO EXCEPT A GO 

34 RETURN 

35 EXECUTIJN COMPLETED - NORMAL EXIT 
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IPAD LEVEL ONE 
(CONTINUED) 



***^»- OUTPUT / RESJLl list ***** 


NUM;3ER TEXT 

1 

Z PHONE uINE CONNECT 

3 VALID OPIRATINb SfSTCh uOb-OI-! INFORMATION 

OPERATING- SYSTEM COMMAND TO EXECUTE IPAD LOS-ON PRC3RAM 
5 ESTABLISHMENT OF A NEN SULiTASK LIBRARY It4 THE Ct. 

0 THE OLD SJJTA3K LIBRARY IN ACTIVE FORM 

7 OS GOHMAN'J TO EXECUTE THE SUBTASK TERMINATION FROGFAM 

5 OS COMMAND TO EXECUTE THE SUoTASK INTERRUPTION PRObRAH 

1 OS COMMAND TO EXECUTE T (E 5UCTASK STEP i caERRUF Tlu N 

PRObRAM 

13 SU3TASK INTERRUPTION COiPLETE 
11 

iz valid log off information 

13 PHJNE LINE DISCONNECT 

IH 
13 

16 SU3TASK LI3RARY ENTRY RE5T0.<ED TO ORIGINAL STATE 

17 A PROCEDURE HiLu bE EXECUTED EQUIVALENT TO THE 
F 0 l. L 0 W I hG INPUTS — 3}lo> 

13 COMPLETION OF TERMINATI3N, THEM PROCEEDING PER OUTPUT 
17 

13 completion of interruption, THEN PROCLEUiNO AS IF I 'iPUT 
13 HAD BEEN RECEIVED. 

2) OUTPUTS 16 AND 13 

21 HOLDING OF THE TERHINATION INTACT SO IT WILL BE 
ENTERED UPON RETURN, THE J PKOCEEOING AS IF INPlT 15 
HAD BEEN ENCOUNTERED 

22 PARSED COMMAND, UPDATED ACTIVITY RECORD 

30 explanatory TEKMIMAL OUTPUT (IF NEEDED), INPUT FEQUEST 

31 INPUT TO 3U3TASK STEF 

36 CURRENT SUBTASK STE^ INrEKKUPTEO IN RE-STARTAbLE F 0 MM 

37 

33 POINTER TO INTE'RRUPTlD SU3TASK STEP PLUS RESTART 
INFORMATION 

3 3 03 COMMAND TO RE-START FFiOM PRECEEDING PAUSE 

A) IPAO PROCEDURE EXECUTED CuNSISlING OF A PAUSE, QUIT, 
DONE, BYE 

“+1 IPAD PROCEDURE EXECUTED CONSISTING OF QUIT, DONE, BY E ' 
42 NORMAL EXIF COGS j-*"' 
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Table 6.1 IPAD System Des ign/Vol ume Mi Requirements 
Comparison Summary 


DESIGN NODE 

DESIGN COMMAND 

CORRESPONDING COMMAND 



FROM VOL. 1 1 1 

E 

Name of Existing Subtask 

RESUME (from HOLD) 


Name of Non-Existing 
Subtask 

No explicit command given 
for the initial log-on for 
a subtask 

F 

QUIT 

HOLD 


STOP 

STOP 


TERMINATE 

No explicit command given 
for the ending of a subtask 


RETURN 

RESUME (from PAUSE) 


HELP 

LEARN IPAD 


SEARCH 

FIND 


CREATE 

ENTER 


MODIFY 

EDIT 


CONSTRUCT 

CONSTRUCT, ENTER 


EXECUTE 

EXECUTE 


DISPLAY 

DISPLAY, FIND, COMPARE 


DISPOSE 

PURGE, SEND, TRANSFER 


DEFINE 

DEFINE 

G,H, i,K,M,N, 


PAUSE 

PAUSE 

0,P,Q,W 


GO 

RESUME (after PAUSE) 

None 

None 

MESSAGE H 
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6.3. SYSTEM MEMBER SPECIFICATIONS 


6.3.1 D esign Ot cf anL'z a*:ion 

Section 6.2 contains the design specifications developed 
using a top down approach. Starting with basic user functions 
at the highest level, the various downward trails or ’’tree 
walks" specify the actions and data flow required by the- system 
to carry out these functions. Viewing the complete system from 
another perspective, four basic operational elements or system 
members are identified whose relationships are shown in figure 
6.4. These elements are: 



Figure 6.4 IPAD System Member Relationships 
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a) ACTIVE JOB — A set of computer operations performing 
work for a user. 

b) OPERATING SYSTEM — The collection of software which 
controls the host computer and provides the interface 
for the non-IPAD user. 

c) IPAD DATA HANAGEB--The collection of software unique 
to IPAD which controls and manages access to data in 
the IPAD data base. 

d) IPAD EXECUTIVE — The collection of software unique to 
IPAD which interprets user commands and controls and 
manages system activities in response to those 
commands. 

No attempt has been made to map the design nodes of section 
6.2 and Appendix A completely into the system members. Table 
6.2 illustrates how this mapping might be done. Identifying 
nodes with system members is primarily an implementation task. 

The concept of community and subtask libraries and the 
underlying system data structures is basic to the IPAD design. 
Implementation guidelines for the IPAD Executive and Data 
Manager are given in sections 6.3.2 and 6.3.3. Specifications 
of the data structures are given in section 6.3.4. 


6-3.2 I PAD Exec u ti ve 

A design goal has been to minimize the IPAD interface with 
any given host hardware/software system. With regard to the 
IPAD executive this implies that it should execute as an 
ordinary job under the host operating system. The degree to 
which this is not true is a measure of the host system 
dependency of any given IPAD executive implementation - 

The most significant result of these considerations is the 
design feature of one executive program per user. If the IPAD 
executive is to look like a user program and there is to be one 
per user, at least three demands are put on the host operating 
system : 

• It must contain a time sharing system with normal 
terminal input/output handling features. 

• It must have a multitasking capability with the 
ability for one task to interrupt another. 
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Table 6.2 IPAD System Member Mapping 


SYSTEM MEMBER 

DESIGN 

NODE(S) 

EXPLANATION 

EXECUTIVE 

E 

Subtask setup 


F 

Subtask command mode 


T 

Subtask step controlled abort 


u 

Subtask interruption 


V 

Subtask termination 

ACTIVE JOBS 

G,H,I,K,M, 

N,o,p,g,w 

All utility operations and user 
appl ication modules. 

DATA MANAGER 

K.C.B. 

Update usage information 



This is an example to show that the 
data manager enters the system design 
at levels 2,3, and below. The data 
manager is support to the executive 
and active jobs and therefore will not 
be visible to level I. Most nodes at 
a lower level will use the data 
manager in same way. 

OPERATING SYSTEM 

N.D.A 

Initiate execution 



The operating system supports IPAD; 
therefore, the interface to it appears 
at the lower design levels. 
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• It must be able to retain the linkage between a user 
and his executing job without maintaining a terminal 
connection. 

The first of these requirements must be satisfied to 
support personal terminals in IPAD. The second requirement must 
be satisified if the executive is to initiate IPAD utilities and 
user jobs, interrupt them, and restart them. The PAUSE command 
(see figure 6.3) may be issued by the user at any time during 
execution requiring the operating system to suspend execution of 
the current activity and initiate a new activity. Repeated 
interruptions are allowed, giving rise to multiple activities in 
suspension associated with a single user/terminal combination, 
since an interrupted activity must be restartable, operating 
system functions like roll-out and roll-in will be callable by 
the IPAD executive. The third requirement is necessary to free 
the user and his terminal during long executions. If an 
execution requires mors than a few minutes, the user may desire 
to pursue other tasks and inquire at a later time about the 
progress of his executing job. ' 


6.3.3 D ata Manage r 


6, 3-3.1 Design Intent 

The IPAD data manager will consist of a set of computer 
programs written in IPADL (see section 6.7) and underlying 
software provided by the host system. The IPADL programs are 
intended to be machine independent but will be dependent on a 
level of data base management software similar to that specified 
by the CODAS.YL Data Base Task Group (DTBG) in their report of 
April 1971, (ref. 4) . If the host system does not include 
software supporting a CODASTL defined data management system it 
is recommended that it be added and used. Other software 
providing the same capability would suffice. At the IPADL level 
of implementation the underlying software should be invisible, 

A fundamental concept in the IPAD data management system is 
the separation of definitions of data structures from programs 
that reference the data. The IPAD stored data definitions are 
the basis for all IPAD controlled data functions as well as the 
means by which implicit I/O is provided to user programs. The 
schema and subschema of CODASYL are stored data definitions, and 
in the following sections modifications to the CODASYL 
specifications necessary for IPAD are given. 
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6.3, 3.2 Hodifications to CODASYL Data Description Language 
(DDL) Specifications 

Ex ter n al Data Structures — Provision for the definition of data 

structures which reside on storage media such as punched cards 
and magnetic tape are necessary for some IPAD utility functions 
dealing with the movement of data into and out of IPAD. 
Subschema should permit the differentiation of external and 
internal structures and include facilities for storage device 
and media control information. Examples are: field definitions 
on punched cards, tape blocking factors and tape mode and 
density. The DDL, as specified in the April 1971 CODASYL report 
of the DBTG, does not handle these problems but perhaps will by 
the time IPAD implementation is begun. Additional work 
currently under way in CODASYL by a new group, the Stored Data 
Definition and Translation (SDDT) Task Group, is dealing with 
this problem. Papers were presented by this group at the 
SIGPIDET Conference on Data Description held in Denver, Colorado 
in November 1972, {ref. 5), The development produced by the 
SDDT Task Group should be evaluated as an early part of the IPAD 
implementation effort. 

Local V ariable ~ L ibr ar y Variabl e Re f eren ces --The CODASYL DDL 

specifications must be modified to allow subroutines to 
reference a global variable with their own local variable names. 
CODASYiL DDL statements for a schema include those for defining 
variables as data subentries of record entries. CODASYL also 
permits the definition of subschema which specify which parts of 
a data set the program declaring the subschema may access, in 
the DDL for a subschema there is a RENAMING section in which 
variables and aggregates of variables (e.g., records) can be 
given names local to a subschema. The CODASYL specifications, 
however, require that all routines which use a given subschema 
use the same local names. The RENAMING section must be 
augmented for IPAD to accommodate the coding module to 
operational module building block logic. The addition of a FOR 
phrase in the DAT A renaming clause provides this augment for 
variables. 

As an illustration: 

DATA data-base-identifier-1 IS CHANGED TO data-base-data-name-1 
FOR subroutine identifier-1 {, TO data-base-data-base-name-2 FOR 
subroutine identifier-2).-.. 

FOR phrases can be similarly used to rename sets and records. 

When a coding module is generated, the subschema required 
for implicit I/O are identified by each subroutine in the CM. 
Two or more subroutines declaring the same subschema may have 
different names for the same variable in the data set identified 
in the DATA statement by data-base-identifier-1. There is a 
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complimentary requirement {discussed in more detail below) that 
all local-global name references be correctly resolved at 
execution time. The modifications specified here for subschema 
renaming can be used directly for this resolution. 

It should be noted that the default mode uses the same 
local and global variable names, and this mode will frequently 
be used when new programs are developed under IPAD. The 
renaming capability is needed, however, for incorporation of 
pre-existing and independently developed code into IPAD. 


6,3. 3. 3 Data Manipulation Language (DHL) for IPADL and the 
IPADL Compiler 

As of this writing the CODASYL DBTG has only specified a 
COBOL DHL. If CODASYL produces a FORTRAN DHL, as planned, it 
should be relatively simple to adapt it to IPADL. If a FORTRAN 
DHL is not available a DHL for IPADL must be specified. 

Assuming the resulting DHL is modeled after the one which 
exists for COBOL, a FIND command issued by a program will cause 
the data manager to move the desired data from the data base 
storage device to a system buffer. A subsequent GET command 
moves all or part of the data from the system buffer into the 
user's working area where it is manipulated by the calling 
program. As mentioned above, different IPAD subroutines may 
reference a single global variable with their own local names. 
Hhen an operational module is executing and a GET command from 
a subroutine has moved some data into the user's working area 
(UWA); that portion of the UWA resembles a FORTRAN common block 
with respect to the data aggregate moved and the other 
subroutines which use the same subschema, Thr.ee conditions must 
be satisfied to provide proper referencing to the data in the 
DWA: 

a) The FIND (or eguivalent command) must identify the 

requestor so the correct data aggregate is retrieved 
from the data base; 

b) The G ET (or equivalent command) must identify the 

requestor so the correct data aggregate is moved to 
the UWA, and 

c) The correct address references are made to variables 
in the UWA from each subroutine using the same 
subschema . 

These requirements suggest modifications to the DHL such as 
adding a FOR phrase t.o the F IND , G ET commands. This, however. 
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would only satisfy condition (a) and partly satisfy condition 
(b) . Alternatively, the IPADL compiler could be designed to use 
the subschema at code generation time which enables it to use 
global names for all retrieval/storage commands, and to allocate 
space for data in the OWA. a mechanism, like FOBTBAN labeled 
COHMOS, would result from the compiler having obtained the block 
structure and the local name equivalences from the subschema. 
All local references, in effect, would then be transformed by 
the compiler into global references without any action by the 
subroutine other than to identify the proper subschema 
compile time. The DHI. should, therefore, include subschema 
declarations. 


6.3.4 Data Str uct ure s 

The IPAD system uses a set of data structures organized 
into libraries as discussed in section 5.4. By convention, all 
data stored in the IPAD data base resides in library entries. 
Each library entry is divided into tsfo parts, the library 
directory entry and the library text entry. The directory 
contains identification and control information pertaining to 
the text. The text is the information set stored. The 
directory/text relationship is essentially the same as an 
envelope /let ter relationship. Figure 6-5 shows the basic 
elements of a library entry. 


LI BRARY 

DIRECTORY 

EKTRY 

LIBRARY 

ENTRY 

LIBRARY 

TEXT 

ENTRY 


Figure 6.5 IPAD Prototype Library Entry 


NAHE 

TYPE 

STATUS 

USAGE INFORMATION 


{text 


The structure of all library entries are defined in the 
system by stored data definitions (SDD) which are themselves 
library entries. By virtue of usage there are two classes of 
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library entries, user and system. User entries are defined by 
tbs user as he supplies the appropriate SDDs. While there is 
currently only one user type library entry (data set) , the 
number of user SDDs is not limited. System entries hold source 
code, binary code, SDDs, etc. There are currently 17 types of 
system library entries, but each one has one and only one 
structure (or SDD) . To contrast the two usages, there are many 
ways one might need to store the geometrical information 
describing an airplane body, but it is not difficult to find a- 
single, useful way to store binary code. 

When the system is implemented, stored data definitions 
will completely define all the system structures and be able to 
process user supplied stored data definitions. Sections 6,3.5 
and 6.3.6 contain specific details about the currently defined 
library entry types. 


6.3.5 Direct ory E ntr y Specfi c atio ns 
a) NAME — Exter n al for m 


N 


Unqualified library entry name 
(ULEN) supplied by the user 


N.V 


N. VgCVj 


V is a simple integer denoting a 
version of N generated for any 
other purpose than error 

correct ion 

V 2 is a corrected version of N.Vj 
and should be used in its place 


N.V(Q) 
N.VgCVj (Q) 


Q is the qualifier attached to the 
IE by the user and possibly ap- 
pended to by IPAD. 


Intern a l F o rm 


This is the external form with the owner's 
identification appended. OID/PW/PP = owner's 
identificat ion. 


OID = owner's identifier 

PW = owner's password active at the 

time the LE was established 
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PP project pointer--linkage with the 

project (could be project or 
subtask) , 

b) type — M ust be one of the following codes 

AL = Alias 

CM = Coding Module 

DY = Dummy 

DF = Display Format 

DC .= Dictionary 

DR = Directory 

DM = Display Menu 

DS = Data Set 

OM = Operational Module 

PL = Plan 

RP = Report 

SDD = Stored Data Definition 

SJ = Standard Job (synonym for Job) 

ST = Subtask 

SF = Security File (see section 6.5 

below) . 

c) STATUS — Ba si c Desc ription One of the items under each 
of the following headings must be selected. 

Availability - (available, purged, archive) 

Security - (unclassified, confidential, secret, 
etc. ) 

Certification Level - (checkout, certified) 

Analysis Level - (1, 2, ...n) 
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Current Structure - (for any LE which nay have 
text in optional formats, the name of the current 
SDD) 

Current State of Acc e ss 

Eor each user currently attached to the LE, the 
user's identification (DID) will be kept along 
with the type of access he is permitted to have. 

Responsible Pers on/Organ iz at b on 

■Identification of "owner” of the LE. 

E xtern al Do cume n t Re f erence 

When applicable, references which are pertinent 
to the text associated with the LDE. 

Te xt C o ntro l Data 

Existence and contents of this category of 
information is type dependent. Specifications 
are given with the LTE specifications in section 

6 . 3 , 6 . 


In stallation Table 

Reserved for host system dependent data which may 
be necessary for successful operation, 

USAGE IHE OBM ATIOH 

Date, time or originating action with owner's 
identification. 

Date, time and type of last access with DID 



Dser access -table 


DID 

READ 

WRITE 

EXECDTE 

EXTEND 

UIDj 

PWj 



PWj 


AC 



AC 

DID2 

PW2 

P«2 




AC 

AC 



OID3 



PW2 





AC ■ 


ANY 



PW4 





AC 


ANY 



ANY 





AC 



AC = Da-te of last access, total access count. 


Note: For the ANY entries, there is the option to keep 

additional statistics by UID. 


6.3.6 L ibra r y Entry S p eci f ica t ions 

The contents and use of the LTE, by type, are specified 
below. The directory entries for some' types of data sets 
contain a collection of control information specific to the 
type. This information, the Text Control Data, is also 
specified below. Table 6.3 contains a summary of the system 
structures. 

a) AL IAS (AL) — The ALIAS type is provided as a 
convenience in resolving data set naming conflicts at the 
operational module and job level. An ALIAS may have a qualified 
or unqualified name, with or without versions. The ALIAS has no 
text of its own but points to another data set. This ’’parent” 
data set may be of any type and has appropriate text. All 
access permission is based on the aliased (parent) data set- 

Co d ing Hodu l e (C M) — A CM is the basic buildinq block 
for the production of executable programs in IPAD. CM names are 
unqualified library entry names with versions and the text 
contains source and object code. The formats of the source and 
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Table 6.3 IPAD System Structures 



Smallest package of computer code tn system. Used 
as a building block to create executable programs. 

A CIVl may have more than one subroutine 


Allow LE names to be used as formal peramoters. 


Allow identification of specific displays. May be a 
user supplied display processor or a parametenza' 
tion procedure for a system supplied display 
function 


All definitions to be stored which give meaning to 
LEs in data base. Used for certain types of reiriev> 
als and user communication 


Used to locate, manage, and control data fLEs) m 
data base. Consists of index in text + the LDEs 
linked to by the index 


Allow users to specify display options for a series 
of sessions 


epository for data repurred by and produced by 
users. Used to coordinate multiple users working 
on a project 


Smallest package of executable code Used as a ' 
building block when defining an execution 
sequence. 


Used for project, task, subtask management, 


REPORT Used for reports produced at tubtask 

(RP) termination time 


COOING 

MODULE 

fCM) 


DUMMY 

fDYl 


DISPLAY 

FORMAT 

IDF) 


OICTION^ 

ARY 

(DC) 


DIREC- 

TORY 

IDR> 


DISPLAY 
MENU (DM) 



STORED 
DATA DEFU 
NITION 
(SOD) 


STANDARD 
JOB (SJ) 


User supplied definition of a data set which con- 
tains sufficient information to allow data access 
by user programs and system utilities to be man- 
aged and controlled by DMS 


The unit of execution in IPAD Us^r defines jobs 
as combination of OM$ and/or other jobs. 


Used by the system to manage a subtask activities 
and subtask library. 


I SECURITY Used by the system to control ecceu to Data base. aULEN 

■file 

t(SF) ^ I 



Air 

Possible 
ULEN Link 

versions Text 

Ui 


/ 1 A , \ , Sub-routine Block for each S-R 

V V V V (See Section 6.3.6B) 


(1) Source code 

(2) Object code 



Ilf! i^ti) System utility ID 
V V V V (2) List of LE names or types which 
may be displayed 


or Job ID (user supplied!, or] Detailed format specifications or other controfl 


QLEN Link 

“ V V 



V V V vvv 


information required by display processor 


Collection of dictionary entries 
(See Section 6.3.6E) 


Index lo a set of LDEs Note that an entire 
library ICL or STU or a part of a l*brarv may 
be referenced by a directory. 


Display option table. 


(1) List of Coding Modules. 

(2) Operational module specificatiortt 

(3) Generated main program. 


‘Pert’* chart with level codes 
User control codes 
CompletionActlon 
Messaoe buffer 


Schema and sub-schema for the data set 
defined by SOD. (Schema use in COOASYL 
sense). 


(t ) Network description of job 

(2) "Symbol table". 

3) Control card skeleton 


O) Activity Record 

(21 Data Set Reference Table 

(3) Termination Record 


User security profiles 






























































































































object code will be compatible with the host software provided 
for maintenance of character string data and for the loading and 
execution of compiled routines. A CH may contain more than one 
subroutine - 


Text Co ntrol Data _ for CH-~A block for each subroutine 

in the CM as follows: 


1) Subroutine Name 

2) Main Program Flag 

3) Entry Point List 

Niame, OM Call Flag 

4) External Reference List 

CM Name, Entry Poin+ Name 

5) Common Regions Referenced and Dimensions 

6) Data Control Specifications, for each data set 

referenced 

- Name: (ULEN) 

- Use: IN, OUT, I/O, Scratch 

- Node: Implicit, Explicit 

- Set up: If mode -• Implicit, subschema name 

If mode - Explicit, file name, position 
of data set on file, and file 
- unit correspondence. 

The information in this block cannot be completely 
specified until the programming language and host software are 
known. The specifications given assume a FORTBAN-like language. 

c) Dummy fP M) — The dummy data set type is provided to 

allow data sat names to be used as formal parameters at OM and 
Job definition time. Substitution of actual data set names for 
the dummy names takes place at execute time. There is no text 
associated with a dummy, and the name is a simple ULEN. 


d) 

identify 
such that 
soft ware 


Displa y Fo rm at [DF)_--7his type of data set is used to 

specific display capabilities provided by the users 
the displays may be readily invoked. The display 
may be user suoplied for a system utility driven by a 
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procedure parameterized by the user. DF names are unqualified 
but may have version numbers. The LTE contains control 
information, format specifications, procedures (which may be a 
combination of IPAD commands and host OS control language 
statements) . 

Te xt C on trol Data for DF 

1) Processor identification 

(a) User supplied Job or OH ID, or 

(b) System utility ID, or 

(c) Procedure flag . 

2) List of LE names or types which may be displayed. 

®> Di ct ion ary ( DC ) — .A dictionary name may be qualified. 
The fundamental purpose of a dictionary is to provide unique, 
unambiguous definitions of data items. The dictionaries are 
used to search the libraries, both through keywords and direct 
references. The LTE of a dictionary contains the individual 
sub-entries. A prototype follows: 

Name (ULEN or Variable name) 

Type 

Defining Text 
Documentation References 
Responsible Person/Organization 
Key Word List 
"Used by" List 

Variables used by Data Sets 
Data Sets used by CMs 
CHS used by OHs 
OMs used by Jobs 

f) Directory (DR) — A directory name may be gualified. 
The text of a directory contains an index which points to a set 
of LEs. A directory is used by the system to access the CL, and 
each STL has a directory. The users do not have direct access 
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to the CL and STL directories that are maintained and 
manipulated by the system. 

g) Disp l ay Men u ( DH ) — Names of DHs are unqualified but 

may have versions. The LTE contains a display option table that 
is used to simplify requests for displays which the user may 
make frequently over the course of working a subtask. 

h) Data Set s {DSl — Data sets contain user data in. the LTE 

whose structures are defined by stored data definitions. Data 
set names are qualified and may have version numbers. 

i) Ppsratiprml Nodule fO N) — An OM is the smallest 

executable unit in IPAD and consists of one or more CHs. OH 
names are unqualified but may have version numbers. The LTE 
contains a list of the CHs. An OK must contain one and only one 
“main” program which is either included in one of the CM 
constituents or produced by the system at the time the OW LE is 
entered by the user. In this case the main program 
specifications are given in a high level IPAD language and the 
source statements are stored- in a separate, newly defined CM. 

j) Piso — The Plan is used to contain control 

information for a project. Plan names are unqualified but may 
have version numbers. The LTE has four main categories of data: 

1) Description of subtasks and PERT type network, 

2) A set of user control codes for each subtask. 
This information is used in conjunction with data 
from the system security file and permission 
codes in the LEs to control activities and data 
access at all levels. 

3) Specifications of actions to be taken on 
completion for each subtask. These include 
references to Report LEs to be produced, the 
establishing of other subtasks, issuing messages 
to subtasks and to project management. 

4) Message buffer used to pass coordinating 

information among active users on a day to day 
basis. 

k) Report (HP) --Reports may have qualified names. The 

report is linked to another LE of type SJ (Standard Job) which 
contains the information required to produce a report at subtask 
termination time. This includes a definition of the contents, 
format, and data sources. The LTE of the Report LE contains the 
actual report produced by the referenced job. 
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l) stored Data Definition tSDDi. — SDD names are 

unqualified" but may have version numbers. The LTE of the SDD 
contains the detailed specf ica tions of the LTE being defined; 
i-e., the schema and subschema referred to in the CODASYL DBTG 
report . 

m) Sec urity F il e fS F) — The security information is 

contained in the LTE. The SF is a unique system LE in the 
community library.- Bach subtask library will also have a 
security file representing the ^total security profile for that 
subtask- Specifications of the LTE contents are contained in 
section 6.5. 

n) Standard Job ( SJ) — Job names are unqualified but may 
have versions. The job is the unit of execution in IPAD and is 
a combination of OMs and/or other jobs. Three categories of 
information are in the LTE. 

1) Network description of job consisting of source 
statements of the job definition language. 

2) A "symbol table" identifying logical file names 
used and the unqualified names of data sets which 
are external to the job. 

3) An execution procedure which is a combination of 

OS. control cards and IPAD commands to be 

parameterized at run time. 

o) SuDtask {ST}_ — Subtask names are unqualified. There is 

one ST type LE in each subtask used to record activities and 
status of the subtask- The ST LE will only appear in subtask 
libraries, never in the community library. Three categories of 
information are contained in the LTE. 

1} Activity Record — A complete record of all 

activities in the subtask such as IPAD commands 
processed and status. Accounting information 
showing resources (cost) used by activity. 

2) LE Reference Table — This information is used to 

determine whether changes have been made to LE in 
the community library which are referenced by the 
subtask from session to session. Current line 
. numbers of the usage information table (in the 
directory entry) of each LE are recorded at the 
beginning and end of each session. Gaps in the 
numbers . between sessions indicate changes. 
Analysis of the usage data will help determine 
■ the effect on a particular subtask. 
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3) Termination Record — The specifications of the 
activities to be performed when the subtask is 
complete are contained in the ITE of the Plan. 
Each activity is logged here when it is started 
and the status recorded, through completion. 
This record becomes part of the project report. 

6.3.7 Logical Organi za tion of IP AD Libraries in Data Bas e 

IP&D data management is based on the use of the system LEs 
to contain the different types of information held in the 
system. The total collection of data in the data base is 

divided into one public aggregate, the community library, and 

many private aggregates, the subtask libraries. With the 

exception of subtask and security file types, LEs of all types 
may be found in any library. 

Access to the data base by the IPAD system is by way of a 
location in the host operating system which points to the 
directory of the community library. This directory is an index 
to all LEs in the CL. Each subtask has a directory in the CL, 

which is an LE of type "Directory” having the name of the 

subtask. The text’ entry of the subtask contains an index which 
points to all the LEs which comprise the subtask library. An LE 
in' the community library may logically be attached to one or 
more subtasks, such attachments being shown in the directory 
entry of the IE. The index of each attaching subtask will in 
turn reference the CL entry. 

Figures 6.6 and 6.7 offer two views of the library 
organization. The first illustrates the chaining of pointers 
which connects the total data base. The second shows what 
resides in the community library and subtask libraries. Note 
that the community library directory is the text entry for a 
library entry called DIRECTORY (CL) , Also note that the subtask 
■libraries consist only of text entries and that all directory 
information resides in the community library. 

The effect of this organization is that subtask libraries 
are only partially visible in the CL. A scan of all the CL 
entries will not disclose any subtask library entries except 
those CL entries which are attached to subtasks, and the 
directories of the subtask libr-aries. Subtask libraries are 
thus seen to be referenced indirectly, one level down from the 
CL. 


A relationship unique to data set type library entries is 
shown in figure 6.8. A data set library entry is composed of 
one or more library variables each of which must be defined in 
the library variable dictionary (see '5.4.2 and 5.4.3). This 
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collection of library variables is then defined in the library 
entry dictionary as a library entry. This then defines a 
conceptual data set which has an unqualified name but no actual 
data associated with it. k collection of data representing a 
particular instance of the defined data set has a qualified name 
in -ehe directory. The directory has the linkage to the actual 
data . 


LIBRARY VARIABLE LIBRARY ENTRY 



Figure 6.8 Data Set Library Entry Origan ization 
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6.4 HOMAN FACTORS 


The characteristics of the man as well as the computer must 
be included in the design of a man-computer dialogue,. The 
ability of man to adapt to a wide range of circumstances directs 
the designer of a man-computer dialogue to give greatest 
consideration to the least adaptive of the two — the computer. 
Too often the needs of the man are determined from a value-based 
definition which leads to the ultimate conclusion that the real 
needs of man are only associated with food, water, and shelter. 
A more useful basis is a rational definition wherein a "need or 
reguirement is some demonstrably better alternative in a set of 
comueting known alternatives that enable a human purpose or 
action to be implemented” (ref. 6) . This definition 
deliberately ignores the argument of value versus cost, an 
argument that is never conclusive in the design of a man- 
computer dialogue. It does allow for an exploration of 
alternatives and their implications on the quality of work., 
efficiency, and general creativeness of man. 

Language is the principal vehicle in a dialogue. Since man 
is the dominant element in the dialogue, the following three 
observations about the behaviour of man are pertinent: 

• Behaviour is strongly time associated. 

• Behaviour is conditioned by familiarity and 

expectation . 

• Familiarity and expectation are the result of 

ex periences. 

These observations are developed as the basis for man- 
computer dialogue design in the following paragraphs. 

6.4.1 U se r Be ha vi our al Ch aracte ristics 

Redaction in computer response time from several days to 
several minutes by going from a batch system to a terminal 
system may be an adequate improvement if the objective is to 
provide a more efficient operation through remote job entry. 
However, if the objective is to establish an environment in 
which the computer is part of a continuous thought process, the 
improvement in response time from days to minutes is not 
sufficient because the human mind requires response tiroes in 
the order of seconds for continuous thinking. Hence, the 
following observed characteristics of the mind play an important 
part in the design of a computing system. 
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Short Term Memory — When tasks are performed, a body of 

inf ormation'”is held in the mind at conscious level, termed 
"short term memory” by Hiller (ref. 6) , Two characteristics of 
short term memory, both associated with waiting, are important. 

a) Short term memory is never passive. Noise from within 
the mind or distractions from without can cause change 
of its contents. The risk of loss of information 
rapidly increases when a person is conscious of 
waiting. Consciousness of waiting occurs within two 
seconds after closure (see below) if new activity is 
not begun. 

b) During creative or highly innovative periods, large 
amounts of work are performed within continuous, 
concentrated, and relatively short time periods. 
Interruptions of less than a minute during one of 
these periods can cause loss of the entire line of 
thought. 


Closur e — Humans spontaneously organize their activities into 
"clumps” (ref. 6) that represent an action that is concluded 
with a definite result. An example, is looking up a number in 
the telephone book followed by dialing the number. At the end 
of each of these activities there is a sense of completion. 
Psychologists call this sense of completion a "closure.” 

A closure is also the point where the minimum information 
necessary to proceed to the next clump is held in short term 
memory. Hence, interruption of a clump of activity results in 
a closure and a partial purging of short term memory to only 
that information necessary to handle the interruption. This is 
observable when dialing the telephone where an interruption will 
cause loss of memory of the number being dialed and, if the 
interruption is intense enough, loss of memory that the phone 
was being dialed. 

When solving complex problems, short term memory is heavily 
filled. The ability of a person to solve complex problems is 
directly related to the amount of information he can hold in 
short term memory and the concentration with which he can 
achieve a chain of closures leading from one conclusion to the 
next. Interruption of this process nearly always results in a 
"restart" and, as stated above, can result in less of the entire 
activity . 

Closures come in different degrees depending upon the 
importance of the result, A person is much more tolerable to 
interruption when an important closure has been reached than he 
is at an intermediate closure. 
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S-tep-Down D is c ontinai t ies — The rate at which thought processes 

decrease in efficiency as the number and length of response 
delays increase is not continuous. Tor example, intense 
creative dialogue is not possible with response times greater 
than 2 to 4 seconds. Ordinary conversational dialogue becomes 
awhuard with response times greater than 2 to 4 seconds and is 
not possible with response times in excess of 15 seconds. When 
two persons are holding the dialogue, the response need only be 
a nod or a grunt but it must occur within the given time period 
to avoid feelings of anxiety or a breakoff of communication. 

Where a continuous thought process involving the computer 
is not a necessary part of the problem solving activity the user 
is engaged in, the above observations and the paragraph on 
response time are not relevant. But it should be noted that the 
user will not engage the computer for some types of activity 
unless he can do so at conversational speeds in a mode that is 
compatible with his thought processes. Useful tasks will still 
be completed when these criteria are not met but some of them 
will be done less well. Direct use of the computer for problem 
solving, creative processes, and complex interrogation requires 
a con verational man-computer dialogue. 


6.4.2 R espo nse Ti mes 

The response times given are those for which the user will 
be comfortable and continue to utilize -the terminal for his 
purposes. They are a quantitative expression of a qualitative 
phenomenon and, as such, are subject to interpretation. 
However, they are based upon study and observation, and, while 
the association between response time and activity may not be 
precise, such an association does exist and is of the order 
given. Response time is defined as the time elapsed between the 
last input by the user and the first character displayed by the 
computer. 

Classificati on s — The following relationships between response 
time and activities are extracted from Miller (ref. 6) and 
Martin (ref. 7). They are illustrated in figure 6.9. 


>1 minute 


Essentially no interactive activity. 


>15 seconds 
but 


(1) Some log-on/loq-of f functions where the 
user is’ familiar with the delay. 


<1 minute {'2) Single enquiries where the user is 

familiar with the delay, preferably 
cued by a message from the computer 
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within 2 seconds acknowledging the. 

command, 

(3) System failures and recoveries, 
preferably cued, where possible, by a 
message from the computer within 2 

seconds warning of the delay. 

{4) Loading of programs and data for 
execution and processing, preferably 

cued by a message within 2 seconds 

acknowledging the command, 

(5) Restart from yesterday. 

(6) Conversational dialogue is not 
possible. 

>4 seconds - (1) Low key enquiry dialogue possible but 

but awkward. 

<15 seconds (2) Intense creative dialogue not possible. 

>2 seconds - (1) Complex enquiries where continuity of 

but thought is necessary. 

<4 seconds (2) Initial acknowledgment by the system 

that it is "listening." 

(3) Error messages. 

<2 seconds - (1) Intense creative dialog . 

(2) acknowledgment by the system that a 
command has been received. 

(3) Response to a paging request through 
a keyboard. 

<1 second - (1) Response to a paging request using a 

light pen. 

<0.1 second - (1) Brightening of characters from a light 

pen selection, 

(2) Appearance of a line when using the 
light pen as a drawing stylus. 

(3) Appearance of a character on a CRT 
keyboard. 
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Interactive 

Capability 



r>l min. 
Effective dialogue 
not possible 


Response Time, r, sec. 


Figure 6.9. Interactive Response Time 


Hiller (ref. 6) recommetnds that error messages be delayed 
for 2 seconds and displayed within 4 seconds. This delay allows 
the user to reach closure before 'he is faced with a need to 
redirect his thought processes to correct errors. Instantaneous 
error messages or error messages that interrupt the user in mid- 
command are disruptive and cause confusion and frustration. 
This is more true for the casual user than for the dedicated 
user. 


The critical threshold for effective creative dialogue is. 
2 seconds. Beyond 2 seconds mental efficiency degrades rapidly. 
Delays beyond 15 seconds should be structured to relieve the 
user of both mental and physical captivity. Experienced users 
will prefer faster response times., 

Devi at ions - -Permissible devia+ions in response times vary. Tn 
general, the permissible deviation depends upon the seriousness 
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of the closare to the user. Besponse times in the 2 second and 
less category should not vary by more than 100^, The curves in 
figure 6.10 from J^artin (ref. 7) are illustrative of good and - 
bad response time deviation characteristics. 


GOOD BAD 



T (seconds) T (seconds) 


Figure 6.10 Response Time Deviations 


6.4.3 User Cl assifi ca ti ons 

Famili arit y — The complexity of each problem step a user is able 
to handle decreases proportionately, if, through unfamiliarity, 
a user's short term memory is filled with personal concern or 
memorized step-by-steo procedures. Hence, the unfamiliar user 
must he helped ■ by decreasing the complexity of each step, 
increasing the number of steps, and increasing the volume of 
reminder information supplied. The reverse is true when the 
user is familiar with the activity. 

Exp ect atio n — Responses strongly dissimilar to the user's 
expectations are the same as an interruption. Less obvious and 
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less critical, but still , important, is the style of the 
language. Quick cryptic language statements may appear course 
and rude to the manager who's day-byr-day business requires close 
attention to a smooth interface with people. On the other hand, 
language that is polite and uses full English may he boring and 
time consuming to the technical specialist. As Martin (ref, 7) 
says, dialogue design must "steer a course between operator 
boredom and bewilderment.” 

Cla ss ification s- -The above factors lead to the following 

classification of users. 

a) Totally Untrained or Novice — This user: 

• is likely to be intimidated by the terminal, 

• is consciously defensive, 

• has his short terra memory almost completely 

filled with information related to learning and 
very little to problem solving, and 

• is easily frustrated by unclear terminal 

responses or unusual response times. 

He requires: 

• programmed learning, 

■a tutorial dialogue, 

• minimum opportunity for error, and 

• display messages that maximize his confidence in 

himself and in the system. 

b) Casual — This user: 


• 

spends most of his time doing something other 
than operating a computer terminal. 

• 

is trained in terminal usage and 
using it. 

feels 

at ease 

e 

remembers general procedures but 
commands and formats, and 

forgets 

specific 

• 

expects to return to a system not 
different from his last use. 

grossly 
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He requires: 

• optional tutorial dialogue, 

• descriptive cues and prompts to remind him of 
missing information, errors in command structure, 
etc- , 


minimized use of mnemonics. 


• 

insignificant change to 
between uses, and 

syntax and 

sequences 

• small deviation in response 

Dedicated — This user; 

times . 


• 

spends most of his time 
terminal , 

operating a 

computer 

• 

has near instantaneous 

structure. 

recall of 

command 

• 

is psychologically tuned to 
of the terminal. 

the response 

pattern 


is adaptive to command structure .changes, and 


• is intolerant to language structure beyond the 
minimum required for uniqueness. 

He requires: 

• abbreviated cues and prompts, 

• maximized use of mnemonics, and 

• faster than normal response times. 


6.4.4 H an-Hachi n e D ial og ue 

The system is visible to the user only through the command 
structure. The command structure of the dialogue is related to 
the system in the same way a person’s speaking habits are 
related to the person. The users expectations will follow 
directly from the class of user he is (as defined in the 
previous section) and his personal nonptofessional 
characteristics. The users psychological acceptance or 
rejection of the dialogue will be based upon how well the system 
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capabilities, language structure, and response times match his 
expectations. 

Tn general, the man-machine dialogue should have the 
following characteristics: 

a) The dialogue should be compatible with the way .the 
task is organized, i.e., the dialogue should be 
flexible where task organizations are variable. 

b) . The extent of the computer responses and those of the 

user should be compatible with the user's training and 
experience. 

c) Completion of an activity should be punctuated by a 
closing act in the dialogue. 

d) Signals should be given when the computer is 
listening, both immediate and interim when the 
computer activity is long. 

e) Where groups of associated data are being input 
through a dialogue, the computer should **clean-up" and 
appropriately display the data at convenient times. 

f) The structure of the dialogue should minimize errors 
at input. 

Specific classes of dialogue are discussed below. 

User In itiated — User initiated dialogue implies a dedicated 

user, or at least a user of such frequency that the dialogue 
commands • are instantaneously recalled. Classes of user 

initiated dialogue are given below. It should be noted that the 
user is leading and the computer is interpreting and responding. 

a) Full English — Because of the alternate meanings of 
words and the context dependency of English 
statements, interpretation of full English syntax by 
the computer is difficult. Further, full English is 
responsive to characteristics of the human mind that 
are not present when the computer is a party to the 
dialogue. Hence, full English is not a viable 
communication language for man-machine dialogue. 

b) Limited English Input — English words and phrases can 
be used where distinctive meanings can be assigned. 
However, use of full English statements where some of 
the words are read by the computer and the rest are 

■ ignored is often confusing to the user. For example. 
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PLEASE DISPLM BEAM ELEM^T NAM ES AND 

IMGINS OF SAFETY WHERE THE'mARGIN OF 
safety“is g reat er than 0^.95. 

In this example, the underlined words are the only 
words interpreted by the computer.- In this type of 
dialogue the user must know the precise words the 
computer will read and their required order. 
Misspelled command words will, of course, be ignored. 
The possibility for misinterpretation is great. The 
temptation to try a series of words without 
determining the command words is also great. Hence, 

this type of "mixed” - dialogue should be limited. If 
used, the actual command read by the computer should 
be displayed back. The above command would be better 
given as 

DISPLAY BEAM ELEMENT NAMES AND MARGINS 
WHERE MARGINS GT 0,95. 

In this command, every word is read and has meaning to 
the computer and the entire phrase has meaning to the 
user. This type of language (i.e., limited English 
without extraneous words, user initiated) is probably 
the most useful language form for the casual user of 
IPAD. 

c) Mnemonics — Mnemonics is the most efficient language 
for the dedicated user. They given great flexibility 
and forego extraneous characters not required to 
uniquely identify the command to the computer. The 
disadvantage is that they must be remembered and 
present little in the form of memory aid. The above 
command might appear in mnemonics as 

D/23 ID, H/*HGT 0.95- 

d) Graphic — This dialogue is initiated by the use,r 

drawing lines, shapes, or symbols; or graphically 

supplying instructions to change the size or location 
of the same either through the CRT face or via an 

electronic tablet. 

e) Pictorial — This dialogue is initiated by the user by 
manually or optically tracing and- marking a drawing to 
be stored in the computer. It may also be initiated 
through calls for display of stored picture catalogs 
with corresponding commands for paging and selection. 
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Comp uter I ni ti ated--Computer initiated dialogue is necessary 
where the user is unfamiliar with the command structure or data 
input formats and must be directed or ’’led through" the 
procedure. It should.be noted that the computer is leading and 
the user is following. 

a) Full/Limited English — Full English commands with 

limited English or mnemonic user responses is the most 
appropriate dialogue where the user is entirely 

unfamiliar with the procedure. Henus, lists of 

alternatives, ejtpla nat ions , and helps are all a form 
of this command. 

b) Mnemonic — ^here the user is entirely familiar with the 
mnemonic set but unfamiliar with order of input, a 
computer initiated dialogue using mnemonics can be 
used. 

c) Form Filling — A form can be displayed giving 

appropriate blanks and headings. 

Hybrid — Combinations of user initiated and computer initiated 
dialogue can be useful. 


6.4.5 E rr or s and Fail u re s 

Effect of Language — The language response must be consistent 
with” the user’s mode. If the user is making a single inquiry, 
he will probably have note of it, and a request for reentry is 
adequate. If the user is making a complex inquiry, it will be 
necessary to display an index of categories or parameters he 
previously input to place him back in context. If the user is 
in 3 conversational problem solving mode, the data he has 
constructed to the point of error or failure must be available 
to him. Beconstructing data is one of the most arduous and 
unreliable activities he performs. Loss of a batch job means 
only that the job must be rerun. Loss of a creative terminal 
job means the model must be reconstructed. Beconstruction is a 
demoralizing activity. Hence, error correction or restart after 
system failure must be responsive to the- user’s need to (1) 
retain confidence in the work thus far completed and (2) retain 
confidence in the terminal as a problem solving medium. 

Diversity of S ou rc e — The integrity of a data set will generally 
be less when multiple independent users are inputting to it than 
when the data is received from a single controlled source. 
Hence, procedures for achieving integrity of the contents of 
data sets increase in importance in a multiple user community. 
The following procedure is recommended. 
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a) Real time dialogue to detect and correct errors. 

b) Software for performing scans, sums, cross file, 

checks, etc., of the entire data set, 

c) Intelligent methods of correcting errors and the 
effects of errors discovered at a time subsequent to 
input and first usage. 

d) Designation of ownership responsibility to some member 
or manager of the user community. 

lliigEES2ii2S5 — Interruptions have been discussed in the previous 
sections. To summarize, interruption of the user to inform him 
of errors or to warn him of impending system failure should 
occur, if possible, at closure rather than during activity. 


6,4.6 System Ba la n ce 

Human factors must be balanced against other factors such 
as cost, hardware capabilities, etc. For example, a dialogue 
that has voluminous computer responses and mnemonic user 
responses overbalances line usage in one direction, which, a) 
affects response time, b) reduces the number of terminals that 
can be multiplexed on a single long line, and c) increases the 
cost of the system. In this instance it may be necessary to 
shorten the computer responses, or store the responses locally 
and trigger them with mnemonic signals from the computer. In 
summary, factors such as transaction time, number of terminals, 
line costs, and human effectiveness must be carefully balanced 
to achieve the most cost effective system. 


6.5 SECURITY 

ft secure system is a design goal of IPAD. Accessable items 
will be protected from unauthorized access and use,> by a system 
of passwords, answerbacks, security classifications, clearances, 
etc. Accesses will be logged so that attempted security 
violations may be determined through security audits. 


6.5.1 D efi n it ions 

Se cu ri ty Cl ass i fi c ation (SC). — The security classification of an 

entity is the total set of all codes, flags, passwords, 
answerbacks, algorithms, access modes, etc., assigned to that 
entity for the purpose of control,' Entities a consist of: 
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• IPAD System 

• User 

« IPAD System Commands 

• Project 

a Subtask. 

« Library Entries 

The security classification assigned an entity will be used to 
control log-on and access as well as functions performed after 
obtaining access. This classification will be denoted SCqj for 
entity a. 

Security Clearance security clearance is the security 

classification for a user. It will consist of the following 
items: 

• Dser ID 

• Password 

• Government or Company assigned clearance, i.e., 

CONFIDENTIAL, SECRET, etc. 

• Allowed operations on specified entities 

Requir ed L og -on o r A cces s Se quen ce — Log-on will consist of the 
sequence of input items requ ired of a user. This may or may not 
be an enforced order sequence, i.e., constitute an ordered set. 
Usually -there will be an acceptable order that might be imposed. 
Hence, it will be assumed to be an ordered sequence unless 

specified otherwise. Each entity will require a log-on sequence 

denoted byal,0t2 , . . . .an . Note that theoi's will be functions of 
a user u so he must furnish the sequence 0H(u), 02 (u), ...,an{u) 
in order to log-on (0= user) or access entity a(Oi^ user). For 
example: 

ai (u) = user User ID 
012 (u) = user Password 

03 (u) = user Clearance - CONFIDENTIAL, SECRET, etc- 


denote the required CX log-on sequence for user u by Lq^(u) . 
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U ser Security Pgof ile ( SP ) — For a given user u with log-on or 

access sequence (u) for entity a , certain rights and 

constraints will be granted and imposed subsequent to a 
successful sequence input. These rights and constraints will 
constitute his i mpli ed s ecurit y c learance I (u) . This 
clearance, together with the required input sequence, will 
constitute the user’s security profile for a, denoted C (u) . 
Hence , 

Cot(u) = L^(U) U • 

Cct (u) will also be called u’s security clearance to access a. 
It should be noted that C^^{u} must be contained in SCq^, i.e. , 

The totality of all such user profiles for each a will be called 
the user’s security profile SP (u) . Hence, 

sp(u) = y cq,(u) . 

Pot e ntial Se curi ty Violation — A user u is required to furnish an 
input sequence Lq(u) , if he is to be validated for log-on or 
access' to entity a. let L (u) denote the input sequence 
actually supplied by u and 1’^^^ (u) the resulting implied 

clearance allowed- Let 

c’qj (u) = (u) U T'a (li) / 

then if 

C’ot (u) ^ Cqj(u) , 

a potential security violation is said to have occured. Thus, 
if a potential security violation (also called potential threat) 
occurs, then L'^ (u) ^ Lq^{u) . The reason for choosing ’’not a 
subset” as opposed to ”not equal” is that a partial input 
sequence (u) Q L(j(u) might be supplied by the user resulting 
in the partial implied clearance I '^ ( u) C Iq^( u) . Hence, 

c”a (ti) G Ca(u) . 

This would allow the user some but not necessarily all the 
access freedoms available. 

Acce ss and S ecur it y L o gs — Two types of logs will be defined: an 

access and a security log. F.ach time a user accesses an entity 
an entry will be made in the access log. This entry will 
consist of the triple (u, a , date-time) . Here, a denotes 

information about the access to a. The access log may exist 
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both as an explicit log used, for example, during IPAD log-on, 
or an implicit log in the case of a data set. In the latter 
case, access information will be saved in the library directory 
entry. 


The security log will be used to log access information of 
a more sensitive nature. In particular, potential security 
violations will be entered in this log. Entries will consist of 
the quadruple (u, a , V , date-time) where a denotes information 
about access to a , and V denotes the nature of the security 
associated with the access to Oi . This could include security 
associated with the access to a . This could include security 
needed and received, type of security threat, which occurrence 
of consecutive threats, severity of threat, etc. 

S ecurity Au d it -- A security audit will be performed periodically 

on the security log to determine attempted security violations. 
This audit will be available in greater or lesser detail, on 
option, to the responsible users and managers. This audit may 
be obtained by request or occur automatically, possibly 
triggered by the severity of some potential threat. 


6.5.2 I PAD Secu rity Initi aliz at ion 

IP AD Sec urit y Fi le — The IPAD security file will contain the 
security profiles of all valid users as well as the security 
classifications for the IPAD system, projects, subtasics, and 
library entries. The file will consist of an explicit part and 
an implicit part. The implicit portion of the IPAD security 
file will reside in the library directory entries of the various 
entitles and the explicit portion will be contained in an actual 
security file. Unless context specifies otherwise the IPAD 
security file will mean the explicit part. 


The 
the IPAD 
security 
system . 
together 
to’lPAD, 


IPAD security file will reside as a proprietary file in 
data base. It will be initialized with a user's 
profile and a security classification for Ot = IPAD 
This will constitute the log-on sequence required 
with the rights of a given user. Each user, to log-on 
roust have an IPAD security file entry. 


Initialization of the security file with a user profile 
will not be allowed in the normal mode of IPAD. This must -be 
done under management control or outside of IPAD. For example, 
a special batch program will be required or only one special 
terminal will be allowed to create and update the security file. 
The initial entries required for a user profile as regards log- 
on sequence are as follows: 
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Optional 

example: 


Dser ID — An identifier assigned a specific user. 
Password — a password assigned a user, 
answerback (Optional) 

• Last name 

• Hother's maiden name 

• Social Security number 

• etc . 

entries needed to complete his profile are, for 


® User may create and enter project definitions, 

• User may cancel a project. 

• User may update another user’s profile. 

» User's profile may not be altered by anyone without 
user's status x. 

• User's status 


• etc. 

The above profile entries constitute the user's profile for 
access to IPAD denoted (u) , 

Project Sec ur ity I nf o rm at io n — Project security information will 

be established as an implicit part of the IPAD security file. 
It will be initialized by someone validated by the IPAD security 
file to enter and define projects. The project plan will 
contain a project security profile for each user associated with 
the project and additional security classifications required by 
the project. Entries in the project plan for a given user may 
be: 

« User ID (input supplied by IPAD log-on) 

• Answerbacks, etc. 

« User can enter and define project plans 

• User may update a project plan. 
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Project related items 




The above entries will constitute the user-profile for access to 
a project, denoted Cp(u) . Note that Cj (u) must also be defined. 

Su bt ask Security Fi le — The subtask security file is derived from 
the project security information. Entries in this file may 
include the following: 

• Subtask Password 

• User may define data sets 

• User may purge data sets 

• User may execute specific subtask related commands 

• User may change his subtask password 

• Subtask related items 

The subtask profile for a given user is denoted Cg,j,(u) . 

Libra ry Ent ry Se curi ty Info r mat ion — This information will 

consist of the user library entry profiles together with library 
entry security classification. Items included in this set for 
a given user may be: 

• Library Entry Password 

• User ID 

<» Access Mode Allowed 

• Read 

• Execute 

• Extend 

• Modify 

• Purge 

• Clearance required, CONFIDENTIAL, SECRET, etc. 

• Accessable time or dates 

• Library Entry related items 
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The library entry profile for a user vill be denoted • 

User Security Profil e — The totality of all profile for all 
entities constitute the user security profile SP(u) which is 
equivalent to his clearance C (u) . Moreover, it also consists 
of all access input sequences required, together with clearances 
granted on successful input sequence submission. Hence, 

c(u) = sp(u) = y cq^{u) = y u 


The last equation may be translated into the following matrix; 



a 

C(u) 


IPAD System 

User ID 

Password 

Answerback 

Projects* etc. 


User IDs 

Password 

Answerback 

etc. 

Subtask 

User IDs 

Password 

Answerback 

Library 
Entries* etc. 

Library 

Entries 

User IDs 

Password 


Acess 

mode etc. 

etc . 






* user is allowed to define these entities. 


The above matrix, in skeleton form except for entries 
needed to log-on to IPAD, will be entered into the IPAD security 
file when a user's profile is initialized. Subsequent matrix 
entries will be made by those validated as project, subtasks, 
and library entries are developed. This matrix will be 
available in the IPAD system for security checking when access 
to various items or function is requested by the user. 


6.5.3 A ccesse s a nd R eq ue st s 

IP AD Log- On — The user must first satisfy the host operating 

system log-on protocol. Having done so, he will enter IPAD by 
supplying his log-on sequence, denoted L'^ (u) . This will 
consist of: 

• User ID 

• Password 

• Subtask Identifier 
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« Answerbacfcs, etc. 

Once his input sequence is complete, 

L’cj (u) e L^j^(u) and I (u) C , 

implying the user’s stated clearance satisfies IPAD’s security 
classification for that user, he may proceed to log-on for his 
subtask. The user will be primarily entering and accessing 
library entries. His right to do so and in what mode will be 
contained in his security profile established to date. 

I PA D Sys te m Requ es ts — Certain IPAD functions are catagorized as 
security classifiable. Examples are: 


«• DEFINE 

• ENTER 

« DISPOSE 

• MODIFY 

• DISPLAY 

• SEARCH 

Each user’s profile will contain persmission codes controlling 
use of these functions. For example, only specific_users will 
be allowed to send data to a remote location or purge a library 
entry from the community library. 

Suspen d ing or R evo king Clea ranc es — At any time, due to a 

security alert, change of project plan, etc., a blanket 

revocation of log-on or access may be imposed- This revocation 
may be made by any one authorized to alter security profiles. 
The revocation will be reflected in all appropriate user 
profiles when entered. An affected user’s progress will be 
suspended the next time his security profile is checked by the 
IPAD system. 

Potent ial S ec ur it y Violati on s — If during log-on, access or 

requesting an IPAD function, a user enters an input sequence 
L'ot(u)not contained in the required sequence LQ^{u), a potential 
security threat exists. This threat will be logged in the 
security log and a threat count started. Depending on the 
severity of the violation; sensitivity of project, subtask, or 
library entry, the threat count will trip a security alert when 
it reaches a certain value. Again, depending on the severity of 
the threat, action will be taken. This action may range from 
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requesting an additional password, certain answerbacks, 
telephone, or even manual verification. If the threat is not 
severe, the user may be logged out. If the threat is severe, a 
security alert may be issued by automatic notification of a 
security office. 


6.5.4 Privacy and Integ rity 

Privac y — Privacy is the right to keep information private to 
oneself and the guarantee that such information will be kept 
safe from unauthorized access. The question of whether such 
information may be obtained and kept is a legal and 
administration question. The IPAD software design allows 
varying degrees of privacy depending on how the security 
controls are used. 

Integrity o f C on tent — A checksum will be made of information 

entered into the TPAD data base. This checksum will be • updated 
whenever the information is altered. A user may request a 
checksum verification, at any time, to determine if a recomputed 
checksum compares with an alleged checksum. To insure that a 
checksum itself has not lost integrity, the checksum will be 
kept with an additional check digit. The checksum verification 
will ensure that, after entering information into the data base 
and determining it to be correct, by visual read out, comparing, 
displaying, etc., any loss of integrity can be detected by the 
user. 


6.6 STANDARDS 

Hebs.ter' s Dictionary defines standard as, ’’That which is 
established by authority, custom, or general consent, as a model 
or example; criterion; test.” 

Standards are necessary for an orderly working world. 
Without them chaos would reign supreme; communication would be 
ineffective or at best,- very difficult; time would be wasted; 
and learning would be severely affected. 

Standards are not to be had without a price. This price is 
paid in work in defining and establishing standards and in 
learning and observing them. Standards have advantages and 
disadvantages. Some disadvantages are: 

• Standards are inflexible 

• Standards stifle creativity 
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However, standards must be inflexible to bring order to work. 
Some also argue that standards stifle creativity and thereby 
confuse creativity with the application or observance of 
standards. The real difficulty with standards are: 

® Standards must be decided upon 

• Standards must be learned and observed 

While most people agree that there should be standards,, it is 
usually difficult for them to agree on what standards should be. 

Standards are necessary for the orderly maintenance of 
activity. They facilitate effective communication, reduce the 
effort required to learn, and insure the effective application 
of education. Standards enhance reliability,, consistency, and 
integrity by reducing errors and mistakes- In summary, their 
advantages are: 

• Facilitate communication, teaching, and learning 

• Save time 

• Insure reliability, consistency, and integrity 

• Minimize errors and mistakes 

• Inflexibility 

When establishing standards an attempt should be made to 
optimize their definition and development, so as to maximize 
their advantages and minimize their disadvantages. 


6.6.1 IPA D De sicr n Sta ndar ds 

Standards have been, adopted in the design of IPAD. These 
standards are given as follows: 

T op Down De si gn — Top down design means starting with 
the most general view of IPAD as seen by the user community, and 
dividing it into constituent parts. Each refinement comprises 
another level in the design. Any one level may be thought of as 
describing what the design at that level consists of, with the 
next level below giving the how of the preceding level. 

Inde pendent Mo dules--The design results in a set of program 
modules that .may be implemented and modified as independently as 
possible from other modules. This is a design standard, and 
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fortunately a consequence of the structured top down design 
process. 

O pen Ended — It is envisioned that IPaD will undergo continual 

development. To accommodate this development and expansion, 
open endedness is a design standard. 

Ma chine I ndepende nce — IPAD as a design is to be independent of 

specific vendor hardware. 

Data Base Ma nage ment — To facilitate I/O, a data base management 
system is a basic design standard of IPAD. All standard I/O in 
IPAD will be through the data base management system. 


6.6.2 IPA D Imp l ement a tio n Stan dar ds 

Standards adopted for IPAD implementation should be 
consistent with those established in the design. Implementation 
standards should be chosen to facilitate program maintenance and 
checkout. The code should be written neatly, uncluttered, and 
readable; it should be written for the novice and not for the 
coder. 

The list of items given below fulfills the above needs. 

La ngua ge — A common higher level machine independent language 
should be adopted, it should be the implementation language for 
IPAD in which most of IPAD would be written. 

Mod u lar an d Open Ended — As code is developed, modularity and 
open endedness should be kept in mind. They are IPAD design 
standards. 

Common Cod e--Areas in IPAD whose function can be served by one 
common block of code should be identified. This will guarantee 
consistency of function; coded, checked out, and performed in 
one place as opposed to many. 

Program Blo ck s — Blocks of program code should be structured in 

an overall sense much like a book or document. The program 
block should contain the following items as a minimum: 

• Title Section — author, date, etc. 

• Revision Section — modification and revision history 

• Abstract Section — stating the purpose, method, etc., 
for the program block 
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Bibliography Section — contains any external references 
related to the program block 


• Usage, Input/Output, etc. — sections describing use of 
the program block, input required, output generated, 
and other such related items. 

® Quality Assurance Section — this would contain a 

description and history of required steps and actions 
needed to checkout and certify this block. 

• Certification Section — this would contain names and 
references of who modified, tested, and approved the 
block for release. 

• Program Section--this would be that portion of the 
block comprising the executable statements, arrays, 
variables, formats, etc. It may be further subdivided 
into structured sections. 

M in imi ze Hos t S yst em Int e rf ace — One critical design goal of IPAD 
is to minimize the host system interface. In the structured top 
down design, the actual host system IPAD interface will be 
delayed to the lowest level possible. Standards will be 

developed for TPAD/Host system interfaces. 

Doc u mentat ion- -The entire program documentation should be 
structured to facilitate programmed extraction for production of 
a particular program document. 

N am i ng Conventi on s — A consistent convention should be adopted 

for naming and distinguishing variables, arrays, tables, 
constants, code block names, etc. These names should be short, 
3 or 4 characters as opposed to long, 6 or 7 characters. Those 
items related to general system activities should be identified, 
named, and used throughout in a consistent manner. 

Coding and D ocumentatio n Co nv ention s — Program coding should 

adhere to the framework of established program structure. 
Executable program statements should be distinguished from 
documentary statements. They may, for example, be offset by 
blank lines and indented, using a hierarchal statement 
convention. 

The executable code program logic should be well 
documented. This documentation should be meaningful and 
uncluttered. Comments should be informative and not merely 
restate executable statements. Liberal use of outline 
conventions, blank lines, and blank spaces should be used. 
Identifying and setting off items with non-blank special 


105 



characters should be avoided at all costs. Embellishments add 
clutter and decrease readability. 

• Variables should always be used with the values 
initialized in one place. Constants should be used 
with discretion. 

• Labels should be lexicographically ordered, increasing 
in the direction code is read. 

Cert if ication — Certification is defined to include checkout, 
approval, and release of a block of code. 

As part of the development of a block of code, a 
description of the checkout necessary should be entered in the 
quality assurance section of the program block. A checkout 
procedure, test data, and code should be assembled and placed in 
a quality assurance library. This will then be used to certify 
the block. Individuals responsible for checkout and approval 
will be recorded in the quality assurance section. The revision 
section will be updated to reflect the change if meaningful. 
The block will be checked out, approved, and released with the 
appropriate entries having been made in the certification 
section. This process will constitute certification. 


6.6.3 IPA D Maintenan c e St andards 

IPAD maintenance can ' include both ongoing development as 
well as modification and maintenance of existing code. All code 
should be developed using the same standards created for IPAD 
implementation. 

All development and modifications should be documented as 
established by the standard. This would include both program 
code annotation as well as updating the modification record 
sections. Development, per se , is to be distinguished from 
error correction. 

Modifications should be described whether resulting from 
development or errors, and the verification procedure documented 
in the quality assurance section. The program code should then 
be tested and certified in the usual manner to insure it will 
work. The checkout procedure, decks, test data, and 
documentation for the current modification should be added to 
the quality assurance library. IPAD should then be re-certified 
for release. 
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6.6.4 IP AD_A££ii cation Standards 

Standards related to the IPAD user interface will be 
determined primarily by implementation. For example, the IPAD 
standard for packaging computing and operational modules will be 
determined when the actual IPAD command language is defined, the 
implementation language known, data base established, and the 
host system hardware configured. Standards related to the IPAD 
user community will also be determined by implementation. These 
standards will deal specifically with a particular IPAD 
implementation and must be user initiated. 

One area related to the IPAD user community and standards, 
however, needs further study. It is an area that greatly 

impacts all IPAD users and should be considered as becoming an 
IPAD standard. This area deals with the following items: 

• Dimensional Units — The metric system of units (MKS) 
might well be taken as an IPAD standard. 

• Constants — Numerical constants such as tt , e, etc- , 
should be standardized with respect to nomenclature 
and significance. 

• Physical Constants — Constants such as: speed of sound, 
gas constant, gravitational constant, etc., should be 
identified and standardized as to units, nomenclature, 
and significance. 

• Physical Variables — The terms: velocity, acceleration, 
mass, force, etc., should be identified and 
standardized as to units and nomenclature. 

• Miscellaneous Terms, Abbreviations, and Symbols — Terms 

such as Mach number, lift, planform; abbreviations 
such as a.m., p.m., hr.; and symbols such as V/ 2 ^ 

/, etc. , should be identified and standardized. 

• Disciplines — Engineering and design process 

disciplines, such as structures, loads, trade studies, 
etc., should be defined and standardized. This could 
include a standard for planforms, a global airplane 
coordinate system, substructure coordinate systems, 
and the like- 


6-7 LANGUAGE REQUIREMENTS 

A substantial number of computer programs currently exist 
that are candidates for inclusion as application modules in 
IPAD. These programs are predominately FORTRAN but other 
languages are represented. Although FORTRAN is a universally 
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accepted language, many dialects exist. additionally, FORTRAN 
contains machine dependent characteristics requiring a specific 
combination of source language statements, compiler, operating 
system and computer hardware. 

It is a design requirement that IPAD- be capable of 
accepting pre-existing application modules. It is also expected 
that IPAD host systems will be on third and fourth generation 
hardware of more than one manufacturer. Further, it is very 
desirable that IPAD have languages for all user functions that 
are independent of the host system- That is, all IPAD functions 
at the user interface should not vary with changes of the host 
system - 

A practical way of handling the investment of the aerospace 
industry in existing FORTRAN programs must be developed 
initially. For the long term, IPAD should accept other 
programming languages such as ALGOL, COBOL, API and PL/1- The 
study made by Control Data Corporation, consultant to Boeing, 
considered; 

a) ’ The general problem of software migration; 

.b) FORTRAN source code migration on third generation 
computers ; 

c) Migration from third generation to fourth generation 
computers ; 

d) The development of a machine independent FORTRAN. 

The final report of this study is . given in Appendix C. A 
recommendation is made in the study for the development of a 
machine, independent FORTRAN language, IPADF, that could be used 
for the implementation of the IPAD system. It is also 
recommended in the study that utilities be developed for 
translating existing FORTRAN application modules into TPADF. 
The need for a machine independent language may be even more 
general than recommended by this study. Such a language is 
referred to elsewhere in this volume as IPADL. 

Languages are also required at the user interface of IPAD. 
One user interface is at the host operating system level through 
languages such as OS360/370 , JCL or CDC 6600 SCOPE or KSONOS 
control statements. The language associated with the IPAD 
commands and utilities must be specified. Human engineering 
factors are given in section 6.4 but the syntactic forms remain 
to be developed. 


108 



ORIGINAL PAGE IS 
OE POOR QUALITY 


7.0 HOST STSTBH SPECIFICATIONS 


This host system specification considers current and future 
hardware and operating system software. Information was 
obtained from several manufacturers of large scale computer 
systems detailing their products. Two sample host system 
configurations have been given based upon: 

a) a Control Data 6600 {Cyber 74) and 

b) an IBM 370/168. 

These computers were chosen for presentation because of their 
widespread use in the aerospace industry. They are illustrative 
and are not intended to be a recommendation of these particular 
manufacturers at the exclusion of others. 


7,1 VENDOR SURVEY 


To maximize portability in the IPAD system design, and to 
insure that all potential hardware was considered in the design 
of the system, all manufacturers of large scale computer systems 
were surveyed. The survey covered the following areas: 

a) Mainframe 

o System architecture, (multiprocessor, etc.) 
o Instruction type, complexity, timing, and rate 
o Character, integer, and floating point 
representation 

o Main memory size/access rate 

o Tnput/outpnt rates and number of channels 

o Multi-programming capability 

. o Time-sharing capability 

o- Reliability 

o Member of a compatible family of computers 

o Cost 

o Public availability date 

b) High Speed Random Access Storage 

o Capacity 

o Transfer rates 

o Latency 

o Dismountability 

o Cost 

o Public availability date 
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c) Hass Storage (^iitrillion bits) 

o Capacity 

o Transfer rates 

o Number of ports 

o Recording media 

o Dismountability 

o Cost 

o Public availability date 

d) Data Transmission Peripherals 

o Rates 

o Capacity 

o Cost 

o Public availability date 

The questionnaire was mailed to the following vendors: ■ 

Burroughs Corporation 

Paoli, Pennsylvania 
Control Data Corporation 

. Minneapolis, Minnesota 
Honeywell Information Systems, Inc. 

Waltham, Massachusetts 
IBM Corporation 

White Plains, New York 
Sperry Rand Corporation, Univac Division 
Washington, D.C. 

Texas instruments, inc. 

Austin, Texas. 

Replies were received from all vendors contacted. They 
were understandably reluctant to divulge future plans but were 
quite willing to supply detailed performance specifications of 
their presently marketed systems. The hardware characteristics 
of the submitted mainframes and peripherals of all vendors 
satisfy the IPAD system requirements. Instruction rate, or CPU 
power, of some systems is sufficient for a small-to-medium scale 
installation. In some cases, a medium scale installation would 
dictate a multiprocessor configuration. A large IPAD 
installation (for example, one capable of supporting the design 
of a supersonic transport as outlined in volume II) would 
require at least one CDC 7600, IBM 370/195, or Texas Instruments 
ASC central .processor. There will be a heavy demand upon the 
timesharing, data storage, and data handling capacilities of 
these systems. The information presented is accurate as of late 
1972. Table 7.1 is a condensed comparison of these computer 
systems. 
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APPROXIMATE 
INST. RATE 


MEMORY 

SIZE/RATE 


I/O 

RATE 


CHARACTER SIZE 
F.P. PRECISION 


COMMENTS 



MILLIONS 
PER SEC. 

MILLION CHAR. 
MCHAR/SEC. 

# CHANNELS 
MCHAR/SEC. 

BITS, 

BITS 


BURROUGHS 

12-18 

7-8 

32/IOP 

6.8 

HIGHLY MODULAR 

B7700 

EACH* 

12 

8/IOP 

40 

MULTIPROCESSOR WITH 
VIRTUAL MEMORY 

CDC 

CYBER 74 
(6600) 

3-5 

.6-1.3 

100 

12 

8-10 

6 

48,96 

OVERLAPPED SCIENTIFIC 
INSTRUCTION PROCESSOR 

CDC 

CYBER 76 
(7600) 

20-25 

1.6-5. 7 
360 

15 

25-30 

6. 

48,96 

OVERLAPPED SCIENTIFIC 
INSTRUCTION PROCESSOR 

HONEYWELL 

1.2 

1-6 

24 

6,9 

GENERAL PURPOSE 

6070/6080 

EACH 

40-90 

6/IOM(l-4) 

28,64 

MULTIPROCESSOR (1-4), 6080 
HAS MANY CHAR. INSTR. 

IBM 

4-7 

.5-3 

7-12 

8 BIT EBCDIC 

THE 370/168 HAS VIRTUAL 

370/165 


16 

1.3-3 

21,53,109 

MEMORY, BOTH HAVE 80 NS. 

CPU BUFFER STORAGE j 

IBM 

15-18 



8 BIT EBCDIC 

elaborate overlap plus I 

370/195 




21,53,109 

54 NS. CPU BUFFER STORAGE 

TI 

30-50 

4-16 

4-12 

8 

1-4 PIPELINE VECTOR/MATRIX 

ASC 

♦ ♦ 

-3200 

28 

21,53 

PROCESSOR WITH VIRTUAL MEMORY 

UNIVAC 

1.8 

7.8 



GENERAL PURPOSE 

1110 

EACH 

12 



MULTIPROCESSOR (2-4) 


♦ Each processor of a multiprocessor machine 

Arithmetic only. Does not include fetch, store, index, and branch operations. 


Table 7.1 Comparison of Vendor Hardware 
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7.2 HABDRARE CHARACTERISTICS AND CAPACITY REQUIREHESTS 


All available large third generation computer hardware 
systems are .capable of supporting an IPAD implementation. 
Limitations are quantitative rather than qualitative. They 
include CPU speed, memoTy site, online mass storage capacity, 
etc. Fourth generation computers from CDC, Texas Instruments, 
Burroughs, and IBM will be much better suited to the expected 
computation and data transfer volume required in a fully 
utilized IPAD system. Additionally, the cost per operation 
(e.g., addition) will drop by a factor of four to six. Timing 
for' 64 bit floating point add operations, for example, can be 
expected to fall below 20 nanoseconds, while the machine cost 
will remain roughly commensurate with today's CDC 7600 and IBM 
370/195. 


7.2.1 Hos t Sys tem 

The characteristics of the hardware required to support an 
IPAD implementation were determined from the studies documented 
in volumes II and III. These studies provided an estimate of 
hardware capacity requirements in terms of; 

o CDC 6600 CPU hours 

o - Input/output rate per CPU second (a measure of CPU 
I/O dominance) 

o Storage required for program libraries 

o Storage required for data. 

Program usage frequency was estimated in the studies from 
surveys of current and projected design practices for an 
organization similar to the Boeing Commercial Airplane Company 
and the Boeing Aerospace Company. These organizations include 
nearly 7500 design and production engineers, who were assumed to 
be involved in one detailed product design and seven concurrent 
preliminary design projects. The characteristics of these 
projects that affect hardware capacity are; 

o computer usage characteristics, including run 

frequency, 

o desired flow time, and 

o interactive terminal requirements. 

Central Pr oce ssing Unit - The CPU is the heart of a computer. 
It is generally the limiting factor with regard to solving 
extremely large problems, or allowing a great number of 
simultaneous timesharing users. 
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A number of computer manufacturers offer highly modular and 
interconnected computer sysfems with multiple instruction stream 
processors, multiple memory modules, and multiple input/output 
processors. This study considers the central processor to 
consist of an instruction processor, memory, and channels or 
memory ports. Computers with multiple instruction processors 
and memory modules are taken to contain one CPU with a memory 
and processing capacity determined by the total capacities of 
the modules. They should have the following characteristics: 

a) Instruction Rate 

Of all the simple parameters used to describe a 
computer system, the CPU instruction rate has the most 
effect on the speed with which the computer can 
produce results. Hence, any specification of 
instruction rate is tied directly to the volume of 
work expected in, for example, a 24 hour period. The 
IPAD host computer system capacity requirements, 
determined in Volume II, included the total number of 
CDC 6600 CPU hours required to support the Boeing 
Commercial Airplane and Boeing Aerospace Companies. 
The company mix is projected to consume 42.1 CDC 6600 
hours, per 24 hour period. This is equivalent to an 
instruction rate of 10 to 14 million instructions per 
second (MIP) , depending on central processor 
utilization. 

b) Multiprogramming Capability 

The IPAD system is inherently multi-simultaneous user 
oriented. This dictates the need for central memory 
write protection from c.oncurrently running programs. 
Read and execute protection would be highly desirable 
but is not required. Also the hardware should support 
task switching in the order of microseconds. 

c) Floating Point Precision 

A CPU to support IPAD must be capable of at least 12 
digit (40 bit) precision, with an exponent range of at 
least -40 to +40 (decimal) . Some IPAD technical code 
modules will contain routines for solving very large 
systems of simultaneous equations, inverting very 
large matrices, solving nearly unstable differential 
equations, and other similar activities requiring high 
precision floating point arithmetic-. In practice, the 
precision needed is dependent upon the problem 
formulation and the algorithm used. Research, design, 
and analysis aoplications on the CDC 6600 almost never 
require double precision (96 bits) . However, double 
precision on the IBM 360 (53 bits) is often required 
and gives satisfactory results. 
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d) Input/Output Bandwidth 

Words input or output per CPU second on a CDC 6600 
were obtained from the workload prediction study in 
Volume III. These predicted IPAD CPU I/O ratios are 
comparable to the average rates for the total work on 
Boeing's CDC 6600. These rates are: 

o 50000 words/CDC 6600 CPU second for IPAD 

application modules, 

o 56000 words/CDC 6600 CPU second for the Boeing 

6600 job mix. 

This is approximately 6 to 8 machine instructions 
executed for each character transferred. A typical 
IBW 370/165 installation for scientific work executes 
about 5 to 10 instructions per character transferred. 
An IPilD host computer should' have an I/O bandwidth 
comparable to these figures. 

e) Hemory Size 

Application modules must be accommodated through an 
overlay technigue, virtual memory, or a very large 
main memory. Virtual memory is preferred because it 
simplifies the design and operation of the data .base 
manager. Application modules in the order of one 
million bytes on an IBM 360-370 or 320K octal words on 
a CDC 6600 are not unusual. 

f) Character Representation 

The hardware representation of alphanumeric and 
special characters in the computer system is not 
important. it is important, however, that the 
computer system support a full upper and lower case 
alphabet and program constructable remote terminal 
control characters (e.g., line feed, backspace, etc.). 
ASCII- 8 should be supported. 

g) Upward and Downward Compatibility 

It is expected that the first IPAD system will be 
implemented on a medium to large scale computer. 
There will be a wide range of user performance demands 
at different installations. It would be an advantage 
to implement IPAD on one or more compa+ible families 
of computers. During the implementation period it 
would be desirable to have a dedicated member of the 
target family for software development and checkout - 

Random ;^cess Storage De vice s - The IPAD system will utilize a 

spectrum of online data storage peripherals. The IPAD data 
management system is designed to take advantage of the speed and 
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capacity of these online data storage devices. High activity 
library entries, or fragments thereof, will be kept on high 
speed, low capacity devices. Inactive subtask libraries and 
currently active community library entries will be sorted on low 
speed, high capacity devices. Project and task histories, old 
experimental data, documents, and other such information will be 
retained on archival devices. 

The specifications below are intended more as a definition 
of terms than a specific requirement. For fourth generation 
hardware, multiply the capacity-transfer rate product by 50. 

a) High Speed, low Capacity Storage 

High speed, low capacity storage will be used 
primarily for program swapping, library indices, and 
small active job scratch data sets. 

A high speed, low capacity device has a latency time 
of less than 10 milliseconds, a transfer rate of at 
least 1.5 X 10^ 8-bit bytes per second and a capacity 
of less than 10"^ 8-bit bytes. Devices in this class 
include fixed head disks (IBM 2305) , drums (UNIVAC FH- 
432) , bulk core (CDC ECS), and future solid state 
memories using, for example, bulk MOS shift .registers 
or magnetic domain techniques. 

b) Low Speed, High Capacity Storage 

Low speed, high capacity storage will be used for 
dictionaries, inactive subtask libraries, large 
portions of active subtask libraries, and currently 
active members of the community library. Library 
entries stored on his class of device are generally 
regarded as permanent, while the high speed, low 
capacity devices contain predominantly temporary 
copies. 

A low speed, high capacity device has a latency time 
between 10 and 200 milliseconds, a transfer rate 
between 105 and 1.5 x 10* 8-bit bytes per second, and 
a capacity between lO'^ and lO^o 8-bit bytes. Devices 
in this class include dismountable moving-arm disks 
(IBM 3330) , non-disraountable moving-arm disks (CDC 
6638) , and magnetic strip storage (IBM 2321 data 
cell) . In the near future some magnetic domain 
devices (Bubbles, DOT) and early holographic systems 
will be in this class. 

c) Archival Storage 

The use of archival storage is a distinguishing 
feature of the IPAD system. It will contain project 
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histories, experimental test data, backup versions of 
current library entries, and online data sets too 
large for other storage devices. 

An archival storage device is defined as having a 
capacity greater than IQio 8-bit types. Transfer rate 
should be at least 10^ bytes per second. There are 
three marketed archival storage systems using 
different design approaches: Laser/aluminized mylar 

strip (Precision Instrument DNICON) , large reel video 
tape (Ampex T3M) , and cassette video tape (Grumman 
Masstape) . 

Onit R ecord Equi pm ent - ftn IPAD host installation may have a 
complement of unit record devices: 

o Card readers (1 to 2000 cards per minute) 

o Card punches (3 to- 600 cards per minute) 

o Line printers (> 1000 lines per minute) . 

The terminal orientation of IPftD greatly reduces the user's 
dependence on punch cards for program and data storage. For 
example, the computer programs used to verify and format the 
system design document in section 6.2. and Appendix A never 
existed on punch cards. The programs were entered, edited, and 
debugged entirely through alphanumeric CET terminals. Card 
readers and punches will still be required in the future, but to 
a lesser extent than today. 

Line printers, on the other hand, will remain important. 
One or more very high speed, single copy printers, would be 
satisfactory for program listings, checkout runs, and most mark- 
up and throw-away purposes. Also required is a high quality 

printer, similar to, but perhaps not as versatile as, today's 
page or photo composer used to compose books and newspapers. 
Such a device will be able to produce document quality tables 
and plots, if not entire documents. 

M ag netic Tape E quip m en t - Half-inch magnetic tapes will be with 

us many years into the future. An IPAD system installation, 
while not dependent upon magnetic tape for its basic operation, 
will require the ability to accept data recorded by offline 
devices, non-IPAD computer systems, pre-IPAD computer programs, 
and IPAD users. The IPAD installation may also be called upon 
to create tapes for offline devices, very long term archival 
storage, and mailing to installations not reachable by a 
network. Since the primary purpose of tape on an IPAD system is 
communication, there must be both seven and nine track devices 
available. 
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Graphica l in put/Ou t put - Graphical input/output devices are not 
necessarily online to the central host computer. For example, 
a digitizer or programmable film reader for loading drawings 
into the system is generally a stand-alone device. 

Two types of plotters are needed. The first is a high 
v-olurae plotter to produce cheap, marginally accurate drawings 
(.01 inch), for check prints and inter-company communication. 
The other is a very accurate (-002 inch) drafting machine or 
flatbed plotter. Drawings produced would be used for 
manufacturing, mockup, wind tunnel, and other purposes. 

In addition there may be a requirement for a microfilm 
plotter, which would be used for reducing and storing drawings 
on microfilm. 

R el i abil ity - The user community demands the freedom from 
considering the reliability of the IPAD host computer when 
planning projects- Computer designers have devised several 
techniques for detecting and correcting hardware errors, for 
example: parity bits, Hamming code correction, and automated 
voltage margin measurement and adjustment- They have served to 
improve the mean time between failure of the computer system 
hardware in the face of increasing logical complexity- The IPAD 
host computer must have a minimum mean •*-ime between failure of 
one to two weeks and should admit to prompt fault detection and 
repair - 


Summary 

CPU Instruction Rate 

Multiprogramming 
Floating Point Precision 
Input/Output Bandwidth 
Memory Size 

Character Representation 


10 to 14 HIP for the total company 
mix, 

3 to 4 HIP for Project I, subsonic 
commercial transport. 

Memory write protect, read/executs 
protect desired. 

At least 12 digits with an exponent 
range of -40 to + 40 (decimal) . 

Transmit one character per 5 to 10, 
CPU instructions' executed. 

Allow -1 megabyte IBM 370, and 
330K CDC 6600 programs to run. 

Full upper and lower case alphabet. 
Terminal function control charac- 
ters. Prefer 8 bit characters. 
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upward and Downward 
Compa-tability 

Random Access Storage 


o High Speed, 

Low Capacity 

o Low Speed, 

High Capacity 

o Archival Storage 


Unit Record Equipment 


Magnetic Tape Equipment 
Graphical Input/Output 


Reliability 


Desirable. 


Some of each. The quantity is to be 
determined at implementation. 

Transfer rate 1.5 x 1.0^ KB. 
Capacity < lO'^ bytes. 

102 k 3 < transfer rate < 1.5x10^ KB. 
1Q2 bytes < capacity < 10^° bytes. 

Transfer rate > 10^ KB. ■ 

Capacity > lO^o bytes. 

High speed card reader/punch. 

Very high speed line printers, low 
cost per page. High quality page 
or photo-composer for documents. 

7 and 9 track, industry compatible. 

Digitizer or programmable film 
reader. 

High volume, marginally accurate 
paper plotters. 

High precision drafting machines. 
Possibly a microfilm plotter. 

Mean time between failure at least 
1 to 2 weeks. 


7.2.2 T ermi n als 

Personal Ter minals - The primary means of man-computer communica- 
tion in the IPAD system is via terminals. This study has classi- 
fied terminals into three main types: 

0 Personal terminals like teletypes or teletype 
replacements , 

0 Interactive graphics scopes, and 

o Remote job entry stations. 

This study has defined a personal terminal to be a terminal 
operated by one person at a time primarily for two-way 
alphanumeric communication with the IPAD host computer. It will 
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be used for constructing and modifying CH's, OH’s, jobs, and 
other library entries. Jobs run on the IPAD host system will, 
for the most part, be initiated, monitored, and interacted with 
using the personal terminal. 

Host of the engineering interaction requirement is easily 
handled fay purely alphanumeric devices like teletypewriters and 
CRT terminals. A CRT terminal should hold at least 20 lines of 
72 characters. Any fewer almost demands a printer attachment. 
Silent printers and other terminal peripheral devices like 
cassette tape recorders, small x-y plotters, low-volume card 
readers, and simple digitizers have been identified as necessary 
or desirable in the engineering design process. Hany 
manufacturers allow for switchable peripherals so that, for 
example, two or more alphanumeric CRT terminals may share a 
single printer. Personal terminals would be connected to the 
IPAD host via a dial-up telephone line. Whether the lines were 
public or private is an Implementation decision. The use of 
dial-up telephone lines limits the bandwidth to approximately 
2000 bits per second which is more than enough for information 
display but may just be adeguate for a cassette tape attachment. 
Through experimentation this study has concluded 110 baud (ten 
character per second message transmission) is conducive to 
boredom, frustration, and work-arounds. Therefore, 300 baud is 
to be considered as a practical minimum line speed. 

Interactive Graph ic s Term inal s - The interactive graphics 

terminal differs from the personal terminal in its ability to 
display vector or line drawings. There is a definite 
reguirement for interactive graphics in an IPAD system. Two 
classes of interactive graphics activity have been identified. 
One class is limited to simple keyboard input and is useful for 
displaying plots and graphs. The other class is the full 
interactive graphical input/output activity associated with 
geometric design and topological problems. Besides the display, 
hardware to support full interactive graphics includes a 
keyboard, lightpen, function keys, analog input devices like 
joysticks, graphical input devices like RAND tablets, and 
hardcopy attachments. Most interactive graphics terminals have 
self-contained minicomputers to refresh the display, poll the 
user input interfaces, communicate with the host system, and 
generally relieve the host system from minor interruptions- 

Terminals containing minicomputers are generally able to 
interface with a large set of peripherals, including printers, 
small disks, slow half-inch tape drives, card readers and 
punches, and telecommunications gear. 

Remote Job E ntr y Termi nals - In a geographically distributed 
engineering community there are flowtime problems associated 
with bulk manual and vehicular transport of computer input and 
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output. A remo.te intelligent terminal connected to the IPAD 
host system via a wideband line would provide medium speed 
printers, punches, card readers; and possibly tapes within 
walking distance of users. Large volumes of newly generated 
data will, for the near future, continue to be in the form of 
punched cards. The remote job entry terminal allows the remote 
user to enter his data into the IPAD data base and obtain a 
printed copy for visual checking and backup. Its medium speed 
printers complement the personal terminal printers when large 
data sets are to be printed- The remote job entry terminal may 
also act as a message concentrator to minimize line costs for 
local personal terminals. 


7.2.3 N et works 

Networks of interconnected computer systems will be 
prevalent in the future as users recognize their advantages. 
Computing power will be distributed, much like the electric 
power industry where failure of one component or subsystem may 
be bypassed with a negligible interruption of service. Access 
and response time will more closely approach optimum when work 
can be partitioned among the network’s computers. 

Through network facilities, specialized installations such 
as ILLIAC IV at NASA Ames, will become available to remote 
users. 

The greatest benefit computer networks hold for IPAD is 
inter-installation communication. Government agencies may pass 
specifications to contractors and receive reports. Contractors 
and sub-contractors can share computer programs and data, 
guarantee consistency of configuration, stress levels, -etc. 
Public libraries of computer programs, standard reference data 
like atmospheric properties, and cross indexes of technical 
literature will serve to organize the engineering design process 
to an unprecedented degree. 

For the near future, an TPAD host system could be connected 
into a wideband packet switching, store and forward network 
similar to the ARPA net. ARPA uses 50 kilobit dedicated lines 
between nodes and special-purpose minicomputers to interface the 
local computer system to the network. The minicomputer is 
responsible for all data transmission and error management. In 
addition it can reconfigure the network in the event of a hard 
line failure. 

During the implementation of the first few IPAD systems, 
careful thought will have to be given to the expected growth of 
networks and network traffic. • Flexibility of the network's plan 
must be sufficient to allow individual hosts to evolve 
separately . 
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7.3 IPAD HOST COMPUTING SySTEK USING K CDC 6600 (CYBEE 74) 

The host configuration in figure 7,1 is recommended for an 
IP&D implementation in a CDC 6600 installation. The 
configuration is based upon the requirements from Volume III and 
those given in section 7,2, The recommended operating system is 
KBONOS 2.1, primarily on the basis of its orientation to 
terminal operations. SCOPE 3.4 would also be acceptable. Two 
critical features, in terms of implementation schedule, absent 
in both of these systems are: 

a) multitasking within a single users terminal control 
and 

b) the ability to log-off the terminal with the job 
active for later log-on and reconnection. 

Implementation of these features would currently involve 
operating system modifications. 

Multitasking is an operating system feature which allows a 
running program to command the operating system to execute 
another program, usually in parallel with the originating 
program. The originating program may obtain status information 
through the operating system and may abort the subordinate 
program and continue in execution itself. This process of 
"attaching” other programs may be nested, or treed, to many 
levels. 

Specific equipment for personal terminals is not included 
because of the rapidly changing technology. However, the 
characteristics to support a selection at implementation time 
are l^isted. The interactive graphics equipment is an example, 
rather than a hard requirement because the specific needs are 
unknown at this time. 

The equipment list for this host configuration is given 
below. A schematic diagram is given in figure 7,1. 

a) CPU and system control equipment 

o CYBER 74-18 CPU (131,072 CM) 

o 6612 system CRT console 

o PP option for 14 PPU’s and 18 data channels 
o Three each 844-2 disc drives with three each 7054 
controllers (to be used for system storage and 
job swapping) 

b) Online data storage for the user 

o Ten each 844-2 disc drives with three each 7054 

controllers 

o Five each 821-2 disc drives with two each 3553 

controllers and two each 6681 data channel 
converters 
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C) 


Tape drives for system and users 
o Two each. 657-4 tape drives (7-track) 
o Four each 659-4 tape drives (9-track) 
o Two each 6681 data channel converters 

o One each 3528 controller 


0P p^4t p 


d) Graphics 

o One each 1700 auxiliary computer with a 6674 

controller 

o Two each 274 display CRT's each with a 1744 

controller 

o One each tape drive with a controller 

o plotters (off line, CRT slave, connected to 

remote batch) drafting machines (offline) 


e) Remote batch entry 

o Two each 732 terminals (4800 baud) with 1 card 

reader and printer each 

o Two each 732 terminals (9600 baud) with 1 card 

reader and printer each 
o One each 6671 controller 

f) Personal terminals 

o Two each 6676 controllers 

o 100 personal terminals 

CRT 

600/1200 baud 

. minimal vector capability 

. TTY interface compatibility 

o 50 shared printers for the terminals 

o 25 shared cassette drives for the terminals 


g) Local batch 

o One each 405 card reader with 3445 controller 

o One each 415 card punch with 3446 controller 

o Two 512 printers with 3455 controllers 

o One 6681 data channel converter 


The CDC configuration of figure 7.1 will support the 
computational load from two design projects similar to Project 
1 (subsonic transport in Volume II) . However, the peak efforts, 
during level 4, in Project 1 (co’nf igura tion refinement) would 
have to be staggered about three months to prevent saturation. 

Project 2 (supersonic transport) would require nearly one and 
one third greater capacity than this host configuration for 
either level 3 (configuration sizing) or level 4 (configuration 
refinement) .. 
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7,U IPAD HOST COMPUTING SYSTEM USING AN IBM 370/168 

The host configuration in figure 7.2 is recommended for an 
IPAD implementation in an IBM 370/168 installation. This 
configuration is based on the IPAD host capacity requirements 
from Volume III and the host hardware requirements from section 

7.2. 


Due to the essential time sharing nature of the IPAD 
system, OS/VS2 with TSO {'^ime Sharing Option) is recommended. 
VS2 was selected because TSO on VS2 allows 42 simultaneous 
active regions, while TSO on MVT allows only 14. The ■‘■wo 

critical features, in terms of implementation time, of the IPAD 
design which currently will require system (TSO) modifications 
are: 

a) implementation of "PAUSE” and 

b) the ability to log-off the terminal with the job 
active for later log-on and reconnection. 

The "PAUSE" command in the IPAD system enables a terminal 
user, at any tima, to interrupt an executing program. He may 
then give a "GO" command to resume execution, or he may enter 
some other IPAD command. At the completion of the inserted IPAD 
command he may resume execution of the interrupted program. 
This process is nested and a user may have several programs in 
suspension at one time. 

The technology of personal terminals is changing so rapidly 
that a specific selection at this time would serve no purpose. 
Particular terminals will be selected at implementation time. 
Four 2250 graphics consoles have been included. This number is 
variable depending on the level of sophistication of the 
graphics technology at an individual installation. 

The equipment list for this configuration is given below. 
A schematic diagram is given in figure 7.2 

a) CPU and Miscellaneous System Equipment 
o 3168KJ CPU with 

. Hiqh speed multiply 

. Buffer expansion 

. , 3 million bytes 

o 3067 power supply 

o 3066 CFT operator’s console 

b) Channels 

o One 2830-1 Block multiplexer channel 

o Two 2880-2 Block multiplexer channels 
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o 

o 


One 2860-2 Selector channel 
One 2870 Multiplexer channel with 
one selector subchannel 


c) Online Data Storage for the Dser and System 

o One 2305 Fixed head dish with its 2835 controller 
o Three 3333/3330 8 spindle disk, systems with three 
3330-2 controllers 

o One 3333/3330 16 spindle disk system with 3830-2 


d) Tape Drives for the User and System 

o Two 3420-5 7-track, multi-density with 3303 

controller 

o Four 3420-5 9-track, 800/1600EPI with 3830 

controller 


e) Graphics 

o Four 2250-3 Interactive graphics terminals 

f) Remote Batch Entry 

o One 2702 Transmission unit, 2-4 high speed lines 

g) Personal Terminals 

o One 2703 Transmission unit, 60 low speed lines 

o 100 personal terminals 

CRT 

. 600 baud 

. Minimal vector capability 

. TTY compatible 

o 50 shared terminal printers 

■o 25 shared terminal cassette units 


h) Local Batch 

o One 2821-5 Unit record controller 

o One 2540 Card reader/punch 

o Two 1403-N1 Printers, with Universal Character 
Set feature 


an IPAD system running on this IBM host configuration would 
be capable of supporting two to three Project 1 (Subsonic 
Transport) efforts in parallel. As with the CDC 6600 host 
configuration, it would be very important to schedule the load 
peaks of the individual projects to minimize saturation. This 
configuration could handle levels 2 and 3 of Project 2 
(Supersonic Transport) provided some rescheduling and stretchout 
were done- to reduce the peak capacity requirements given in 
volume III. 
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Figure 7.2 IPAD Host System -IBM 370/168 
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APPENDIX A 


DETAILED SYSTEM DESIGN SPECIFICATIONS 

Structured programmiug is a formal work dealing with 
software engineering and hardware-software system design and 
development (ref. 1, 2, and 3) . The objective of this work is 
to transform the development of computer systems from a seat-of- 
the-pants art to a disciplined technology. This approach has 
been utilized to develop the .IPAD system design. 

The structured programming approach is a top down design 
method in which the design proceeds from the general to the 
specific. Each refinement is a level in the system design. 
Tree structure diagrams give the system functional components in 
levels of increasing detail. The nodes at any one level in the 
tree structure are states of activity for the system. The 
entire system is included in the total set of nodes of each 
level, and in fact, higher level nodes are summaries of lower 
level nodes. 

Transition diagrams describe how the system components, at 
each level, are functionally related. The diagrams also specify 
the conditions under which there will be a transition or state 
change within a node or from one node in the tree to another 
node at the same level. These transition conditions are (1) the 
input data or conditions that trigger the transition and (2) the 
output data or results existent in the system at the time the 
transition is made. Figure A. 1 is a sample tree structure and 
transition diagram for a three level system. 

The IPAD system design given in .appendix A follows the 
general form described above. In. level 1, twenty-nine nodes or 
states are described. Except for a few level 1 states dealing 
with hardware or host operating system protocol, the level 1 
states are each refined into level 2 states. The level 2 states 
are, in turn, broken out into level 3 states, and so on. The 
emphasis in the design was placed upon consistency in detail 
rather than consistency in levels documented. Hence, there are 
differences in the depth or number of levels reached in some of 
the tree branches. 

While the design as presented is in top down form, the 
actual design process does, not proceed monotonically. 
Generally, design at level n will result in a review of some 
elements of the design at level n-1, n-2, etc. The advantage of 
the method is that the examination of effects is an orderly 
process and the conseguences of the iterative design process are 
highly visible. 
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TREE STRUCTURE DIAGRAM 


A. A. A 


A.A.B A.A.C A.B.A 


TRANSITION DIAGRAMS 


( input/conditions, 

output/results ) A.B 



{ input/conditions, 
output/results ) 


A ■ A • A ■ 


A.A.C 


N ( Uc, o/r ) 


( i/c, o/r) 


.( i/c, o/r ) \ 


( i/c, o/r ) 


A.B.B 


Figure A.l Structured Programming Diagrams 
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Each level in appendix A contains the following • diagrams 
and tables: 

State Descrip tion T ab les - Three pieces of information are given 
for each node: 

a) short structured Name - This name consists of a set of 
one or two alphabetic characters catenated in' the form 

rs 

rs.tu 
rs. tu. vw 
etc . 

The syllable position denotes a level. For example, 
if node A is at level 1 then node A.B would be at 
level 2 and would be a state of node A. Hence, ' the 
tree diagram can be formed from the short structured 
• names. There is no requirement that these names be in 
sequence, i.e., the existence of node A.B and node A.D 
does not presuppose the existence of node A.C. 

b) Long Name - This name is descriptive of the function 
of the node. For example, node E has the long name 
"Subtask Set-Tip." 

c) Description - Several sentences, in summary form, 
describing the capabilities of the node. 

A ll owed Tra ns i tion Tab le s - This is a tabular representation of 

the connections between the nodes having a common parent at the 
next higher level. The states from which and to which 
transitions are made, along with the corresponding references to 
the input/condition and output/result tables which follow, are 
given. A bent arrow is used to flag entry and exit points from 
the parent node. When exits are shown, the level of ' the state 
exited to may be at a higher level than the state being exited 
from depending upon the level of tree structuring completed. 

Tr ansition Diagrams - These are a graphical representation of 
the allowed transition tables. They can be constructed from the 
transition tables and are valuable for visualizing 
relationships. 

Input/Condition s List Ta bl es - This is a list of the input or 
conditions that trigger a transition or change of state. This 
list should be used in conjunction with the Allowed Transition 
tables. 
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Ou t p ut /Resul t L ist T ables -• This is a list of the output or 

results that are existent in the state when a transition- is 
made. This list should also be used in conjunction with the 
Allowed Transition tables. 

Abbreviations are not used in level 1. They are used in 
lower levels to facilitate writing. Definitions of 
abbreviations are given in section 4.0 of Volume IV. The text 
part of appendix A was created by a computer program from data 
supplied by the system designers. This computer program checked 
for consistency to ensure that transitions were made between 
valia states and that lower level states were correctly 
referenced to higher level states. 

Tree diagrams are not included. They can be constructed 
from the structured names. 

Figures A.l and A. 2 are the level 1 transition diagram. 
Node F is repeated on figure A. 3 for reference. These figures 
should be read in conjunction with the State Descriptions, 
Allowed Transitions, Input/Condition List and Output/Result List 
following the diagrams. Transition diagrams for lower levels 
are included with the level. 
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IPAD System Design Levei I 
Transition Diagram 
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COs'lPONEinS OF I?AO LEVEL ONE 


ORIGINAL PAGE IS 
OF POOR QUALITY 


STATE 

A 


C 

0 

F 


STATE OESG^IPTICNS **’>■** 


LONG NAME ANO TEXT 


PERSONAL TERMINAL OFF 
THE EN'JIPMENT li NJT ACTIVE. 


PERSONAL TERMINAL ON 

THE EQUIPMENT IS ACTIVE -iUT NO DATA PATH TO THE 
COMPUTER EXISTS. THE EQJiPHENT A PERSONAL TtRMINAL, 
NOT A remote JG'J CNTRl' TERMINAL, BUT MAT BE AUGMENTED 
WITH PEtilPHERAL OEVIOtS SUCH AS CASSETTE T A“E , FRIN TER , 

Plotter. 


PERSONAL TERMINAL CONNECTED 

THtRE NOW EXISTS A TWO-WAY DATA PATH BETWEEN THE 
TERMINAL AND THE COMPUTER 


OPERATING SYSTEM COMMANu MODE 

THE USER IS NOW ADLE TO ENTER COMMANDS TO THE TIME 
SHARING SYSTEM IN THE HOST OPERATING SYSTEM 


SJ3TASK SET-UP 

THE USER IS NOW IN GGMHUQICaTION WITH IPAG AND HE 
IS either INITIATING A Nnw SU3TASK OK CONTINUING AN 
OLJ ONE, IN EITHER CASE, THE NET RESULT WILL 8E THE 
ESTABLISHMENT OF HIS ACTIVE SJ8TASK LIBRARY. 


SU8TASK COMMENT! NODE 

THc USER IS NOW AOLE TO ISSUE IPAO EASIC LOMMANOS 
TO ADVANCE HIS SUSTASK WO<K. 


A7 



IPAD- LEVEL ONE 
(CGNTINUEO) 


STATE 

G. 

ri 

I 


K 


STATE DESCRIPTIONS <CONTInUEO> 


LCN3 NAHL and text 


LEARNING A30JT IPAO 

THE ACTIVITr OF GAINING INFORMATION ABOUT IPAO 
EITHER AS A TAUGHT COURSE CR AS H£L= WlTh A SINGLE 
COHHANO OR MOOUlE. 


SEARCHri'JG THROUGri THE LIBRARIES 

THE “ROChSS OF SCAN'ilUG JiCTIONARIES ANG LIRECT- 
ORIES TO lOEiNTIFY ANU lJOATE INFORMATION IN THE IPAj 
DATA BASE. 


CREATING -i->--.AKY ENTRIES 

THE PROCESS CF INSERTING DATA (NUMERICAL »iNO C IH- 
ER) INTO TnE IPAO DATA -iASt RESULTING IN NEW lIORAFY 
ENTRIEStLE), iNCLUuEO IS THE ENTERING OF SCURCb CODE 
FOR COOING MOUULESCCrl) , INFORMATION FOR i.TOREO DATA .J£F- 
INITIOiNS(S JO) , INSTANCES OF DATA SETS ( US ), DISPLAY MENUS 
(OH), And THE INSTANCE OF THE SYSTEM DATA SET CONTAIN- 
ING ACCESS AND PERMISSION CODES. 


HOOIFYING library ENTRIES 

ALTERING CURRENTLY .RtoiuENI LIBRARY ENTRIES. THIS 
CAN INVOLVE CHANGES TO ANY VALIu IPAD lI-RARY ENTRY' 
TYPE. 


CONSTRUCTING A JOB 


ARRANGING AVAILA&LE CODING MODULES (Cri) INTO OPER- 
ATIONAL MOJUlES(OM), OPERATIONAL MODULES INTO JOBS, AND 
OPERATIONAL MCDULES AND PrEVlOUSLY DEFINED JOBS tnTJ 
NEW JOBS. 
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IPAD LEVEL OME 
(CONTINUED) 


STATE DESCRIPTIONS (CONTINUED) 


STATE LONG NAME AND TEXT 


N EXECUTING A JOti 

ACTIVATING A PREVIOUSLY CONSTRUCTED J03 


0 . COMMUNICATING WITH A JOb 

BEING iNTERA'CTIv/E WITH A USER CONSTRUCTED JOB 


P OISPLAYlNi RESULTS 

SCANNING, CHECKING, AND INTERROGATING I NFCRMA T UN 
CONTAINED IN LlJRARY ENTRIES OF ANY TYPE. 


Q DISPOSITION OF LliRARY ENTRIES 

TRANSFERRING LIBRARY ENTRIES BETWEEN IPAO LIB- 
RARIES , SENDING ITEMS OJTSIUE OF IPAD (OFFLINE , OR VIA A 
COMMUNICATION NETWORK), AND REMOVAL OF UNWANTED LIBRARY 
ENTRIES FROM' THE DATA RASE. 


T ‘ SU3TA3K STEP CONT^'iOLLED ABORT 

THE TERMINATION OF TuE CURRENTLY INTERRUPTED SJB- 
TASK STEP. 


U SUBTASK INTERRUPTION 

ACTION AIMED AT TEMPORARY INTERRUPTION OF THE SJ3- 
TASK ACTIVITIES WITH THE INTENT OF RE-STARTING AT A 
LATER TIME AT -THE PRECISE POINT OF INTERRUPTION. 
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IPAD LEVEL ONE 
(CONTINUED) 


STATE 

V 

W 

GA 

HA 

lA 

KA 

MA 

NA 


STATE DESCRIPTIONS (CONTINUES) 


LONG NAME AND TEXT 


S-J3TAS< TERMINATION 

THE USER HAS COMPLETES THE DEFINED SUBTASK AND 
NOW DESIRES TO DISPOSE OF AlL REMAINING INFORMATION, 

LOG THE TERMINATION IN THE PROJECT PLANS, AND ISSUE ANY 
REQUIRED REPORTS. 


DEFINING library ENTRIES OR VARIABLES 

A DEFINITION IS A DICTIONARY ENTRY WHICH CONTAINS 
THE MEANING OF A VARIABLE OR A LIBRARY ENTRY AND CROSS 
REFERENCING INFORMATION. AlL COMMUNITY LIBRARY ENTRIES 
AND VARIABLES REFERENCED IN DATA SETS .REQUIRE l-EFIK- 
ITIOnS. DICTIONARY ENTRIES ARE OPTIONAL FOR SUtTASK 
LIBRARY ENTRIES. 


INTERRUPTED LEARNING AoOJT IPAD 

THIS IS THE STATE IMMEDIATELY FOLLOWING “A” 

PAUSE’ DURING LEARNING ABOUT IPAD. EACH OF THE STATES 
G, H, I, K, M, N, 0, P, Q, AND W HAVE A SIMILARLY 
ASSOCIATED STATE. 


INTERRUPTEl) searching through LIBRARIES 


INTERRUPTED CREATING lIBRARY ENTRIES 


INTERRUPTED MODIFYING LIBRARY ENTRIES 


I'TTER'RUPTCO CONSTRUCTING A JOB 


INTERRUPTED EXECUTING A JOB 
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IPAO LEVEL ONE 
(CONTINUED) 


♦ STATE DESCRIPTIONS (CONTINUED) *■»■*** 

STATE LONG NAME ANO TEXT 

CA INTERRJRTEO COMMUNICATING WITH A JOB 

PA INTERRUPTED DISPLAYING RESULTS 

QA INTcRRUPTED DISPOSITION OF wldRARY ENTR. 

WA INTERRUPTEU DEFINING ^ISRARY ENTRY/VAR 



All 



IPAD LEVEL ONE 
(CONTINUED) 


♦*»»» ALLOWED TRANSITIONS ***** 


FRON STATE TO STATE INPUT / OUTPUT / 

= ENTkr) (.♦ = EXIT). CONDITION RESULT 


B 

1 

■4 

A 

lA 

14 

C 

2 

£. 

A 

14 

13 

.B 

13 

13 

□ 

■ 3 

3 

A 

14- 

13 

il 

13 

15 

8 

15 

i‘; 

C 

12 

12 

E 

4 

4 

A 

14 

? r 

d 

15 

lb 

F 

5 

5 

F 

6 

C 

V 

16 

6 

A 

14 

17 

a 

13 

17 

G 

17 

22 

G 

34 

39 

H 

13 

22 

h 

34 

d9 

I 

19 

22 

I 

34 

39 

K 

21 

22 

K 

34 

39 

M 

23 

22 

M 

34 

39 

N 

24 

22 

N 

34 

59 

0 

34 

39 

P 

27 

22 

P 

34 

39 

a 

23 

22 

a 

34 

39 

T 

9 

c 

U 

3 

c 

V 

1 

7 

w 

20 

22 

w 

34 

39 


A12 



ORIGINAL PAGE I& 
OF POOR QUALITY, 


IPAD LEVEL ONE 
(CONTINUED) 


ALLOWED 

TRANSITIONS 

(CONTINUED) 


FRON STATE 

TO 

STATE 

INPJT / 

OUTPUT 

(r* = ENTRY) 

(i* = 

EXIT) 

CONDITION 

RESULT 

G 

A 


lA 

<+1 


3 


13 

4G 


F 


35 

42 


GA 


31 

3fc 

H 

A 


' IL 

4u 


3 


13 

4C 


F 


35 

42 


HA 


31 

36 

1 

A 


lA 

4C 


a 


13 

4C 


F 


35 

42 


lA 


31 

3 fc 

K 

A 


14 

*+£ 


o 


13 

4C 


F 


35 

42 


KA 


31 

3t 

H 

A 


14 

4 £ 


3 


13 

4£ 


F 


55 

42 


MA 


31 

36 

N 

A 


14 

4t 


3 


13 

41 


F 


35 

42 


0 


25 

22 


NA 


31 

36> 

0 

A 


14 

4: 


B 


13 

4C 


F 


35 

42 


iM 


26 

22 


OA 


31 

36 

P 

A 


14 

4G 


B 


13 

4C 


F 


55 

42 


PA 


31 

36 

Q 

A 


14 

4L 


B 


13 

4C 


F 


35 

42 


QA 


Si 

3 6 

T 

A 


14 

le 


3 


13 

18 
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IPAD LEVEL ONE 
(CONTINUED) 


allowed transitions (CONTINUED) ***** 


FRON STATE TO STATE INPUT / OUTPUT / 

(r» = ENTRT) { r» = EXIT) CONDITION RESULT 


u 

A 

14 

18 


D 

13 

1 ^ 


0 

11 

11 


E 

10 

1C 

V 

A 

14 

21 


8 

13 

21 


0 

11 

11 


E 

10 

1C 

w 

A 

14 

4 0 


fi 

13 

4C 


F 

35 

42 


WA 

Si 

36 

GA 

A 

14 

*+C 


8 

13 

41 


F 

35 

3t 


G 

32 

37 

HA 

A 

lA 

hC 


3 

13 

41- 


F 

33 

3 c 


H 

32 

37 

lA 

A 

1^ 

“4C 


0 

13 

41 


F 

33 

3c 


I 

32 

37 

KA 

A 

14 

40 


8 

15 

41 


F 

33 

36 


K 

32 

37 

MA 

A 

14 

‘fC 


3 

13 

41 


F 

33 

36 


M 

32 

37 

NA 

A 

14 

4.C 


0 

13 

41 


F 

33 

3b 


N 

32 

37 

OA 

A 

14 

40 


3 

13 

41 


F 

33 

38 


0 

32 

37 
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IPAD LEVEL OME 
(CONTINUED) 


♦♦♦*♦ ALLOWED TRANSIT! DNS (CONTINUED) ***** 


FROM STAIE 

TO STATE 

INPUT / 

OUTPUT 

(<* = ENTRY) 

(f* = EXIT) 

CONDITION 

RESULT 

PA 

A 

14. 

4i2 


B 

13 

- 41 


F 

33 

36 


P 

32 

37 

OA 

A 

14 

4C 


B 

13 

•41 


F 

33 

36 


Q 

32 

37 

W A 

A 

±‘* 

4L 


B 

13 

41 


F 

33 

36 


W 

32 

37 


A15 



IPAO LEVEL ONE 
(CONTINUED) 


IMPjj / CONDITION LIST ^‘f-*** 


NUMBER TEXT 

1 SWITCH TURNED ON 

I DIAL UP 

3 VALID OS LOG ON INFORHATiON IN THE PROPER SEQUENCE 

if VAlIU os command TO EXECUTE IPAO 

5 VALID SUBTASK IDENTIFIER FOR A NON EXISTING SUDTASK 

6 VAuIO SUBTaSK IDENTIFIER FDR AN EXISTING SUdTASK 

7 TERMINATE 

i QUIT 

6 STOP 

11 ANOTHER 

U GONE 

12 HElLO 

13 USER hangs up 

14 SWITCH TURNED OFF 

15 o VE 

16 SU3TASK RECORDS SHOWING AN INTERRUPT OCCURRED OURINj 
THE 3U3 TASK TERMINATION 

17 HELP 

13 SEARCH 

ID CREATE 

2j define 

21 MODIFY 

23 CONSTRUCT 

24 eXECUTc 

25 CONOITiON CODE SHOWING TERMINAL INPUT IS REQUIRED 

26 LAST LINE JF USER INPUT 

27 DISPLAY 

23 DISPOSE 

31 PAUSE 

32 GO 

33 ANY COMF5AND EXCEPT A GO 

34 RETURN 

35 EXECUTION COMPLETED - NORMAL EXIT 
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original PA(JB>U 
OR Poor qualet^ 


IPAD level one 
(CONTINUED) 


***** OUTPUT / KtSULT list ***** 


NU'iUER 


TEXT 


i 

3 

-f 

5 

0 
7 

1 
d 

iJ 

11 

12 

13 

IL 

15 

16 
17 

15 

13 

23 

21 


22 

3J 

31 

36 

37 
33 

35 

L3 


41 

42 


PHONE LINE CONNECT 

valid OPE-^ATING SYSTEM lJC-ON INFOPMATION 

OPERATING SYSTEM COMHAN3 TO EXECUTE IPAJ uOG-OK PROORAH 

lSTAcsLISHNEnT of a Nli^ 5J2TAS.< lISKARY In THE Ll 

THE Old SJ3TASK LIBRARY IN ACTIVE FORM 

OS COMMAN.D TO EXECUTE THE SUBTASK. TEP.Kl .‘J A TI ON FRO^RaM 

03 COMMAND TO EXECUTE THc 3JBTASK INTERRUPTION PROGRAM 

OS COMMANJ TO EXECUTE THE SUOTASK STEP IN TERPsU FT lU N 

PROGRAM 

SU3TASK INTERRUPTION CO PLETE 

VAuIU lvG off INF0R3ATIJN 
PHONE LINE DISCONNECT 


SUBTASK LIJRARY ENTRY R.ESTOREO TO ORIGINAL STATE 
A PROCEDURE HIll oE EXECUTED EUUI.VALENT TO THE 
FOLLOWING INPUTS - -5,13. 

completion of TERMINATIO-^ , THEN PROCEEDING PER OUTPUT 
17 

COMPLETION OF INT ERRu P T Xu N , THEN PROCEEDING AS IF INPUT 
IS HAD BEEN RECEIVED. 

OUTPUTS 15 AND 13 

HulOiNG UF THE TERMINATION INTACT SO IT WILL 3E 
ENTERED UPON RETURN, THEN PROCEEDING AS IF INPUT 13 
HAD BEEN ENCOUNTERED 

PAR3EU COMMAND, UPDATED ACTIVITY RECORD 

EXPLANATORY TERHINAu OUTPUT (IF NEEDED),' INPUT REOUEST 

INPUT TO 3J8TASK STEP 

CURRENT SUUTASK STEP INTERRUPTED IN RE-3TARTABLE FORM 

POINTER TO INTERRUPTED SUbTASK STEP PLUS RESTART 
INFORMATION 

OS COMMAND TO RE-START FROM PiEGEEOING PAUSE 

IPAD PROCEUURE EXECUTLu CONSISTING OF A PAUSE, QUIT, 

DONE, DYE 

IPAD PROCEDURE EXECUTED CONSISTING OF Q-JI T , DONE , uY E 
NORMAL EXIT CODE 
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O O' 


LE\IEL 2 

COMPONENTS OF STATE E 
SJBTASK SET-UP 


STATE 

E.A 

E. J 


***** STATE DESCU-pTICNS ***** 


LONG NA'^iL ANO TEXT 


iPAU lOG-0'1 

USE-^ SUPPLIES HIS USE^ IJ, PASSWORD, AND 
SU3TASK IJelNTIFIER. THE SYSTEM WILL- CHECK FOR 
USER VAlIOTY ANJ. THE EXISTENCE OF THE SJ0TA5K. 


ke-activat: olo subtask 

GIVEN AO INACTIVE SuETASK NAME, -RrSTORE THE 
UOTASK LIBRARY TO ITS PRE - INTERRUPTED STATE. SPECIAu 
ONSIOCRATIONS ARE NECESSARY IF THE INTEF.KUPT COCURREO 
DURING SUSTA3K TERMINATION. 


create NEH SJ 3TASK 

INITIATE A SUBTASK HIll GENERALLY DEPEND UPON THE 
EXISTENCE OF PRJJECT PLANS REFERENCING SUCH A SU3TASK. 
ADMINISTRATIVE CONTROL HiLL BE EXERCISED PRIMARILY 
THROUGH THIS MECHANISM. SUBTASKS WITH NO FORMAL 
PROJECT RELATIONSHIP MAY EE HANDLED THROUGH A SPECIAL 
CATCH-AlL PROJECT. 




rluOwej Transitions 


FROM 

STATE 

TO STATE 

INPUT / ■ 

OUTPUT 

ir» = 

ENTnY) 

(h = EXIT) 

CONDITION 

RESULT 

t*£ . A 


E . A 

6 ~ 

c 



E . 6 

i 

1 



E.C 

2 

2 

E .0 


r»F.A 

3 

3 



f* V .A 


. 3 

E .0 


E.C 

7 

6 



f* F » A 

h 

A 
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E t SU9TASK SET-UP 
(CONTINUED) 


INPUT / CONDI riCN list 


NUN-3ER TEXT 

1 USER 10 AND THE NAME OP A CURRENTLY INACTIVE SU-JTASK 
I USER ID ANJ A SJoTASK NAME NOT RESIDING IN THE CL 

3 VALID SUBTASK L'E IN THE CL 

4 ALl INFORMATION NECESSARY TO INITIATE A SU3TASK. 

3 INDICATION- IN THE SJOTASK L£ THAT TERM! -lA Ti ON NAS IN 
PROGRESS WHEN THE JSc.R HuHG UP OK TURNED THc. SWITCH 
OFF. 

6 INSUFFICIENT VALIDITY CHECK INFORMATION 

7 INITIALIZATION INFO ^MA T I-jN PCR USER uPTICnS ANO/OR 
PROJECT RFUJIRtMENTS 


OUTPUT / RESJlT LIST 


NUMiER TcXT 

i LOGATION OF THE SU6TASK TU BE ACTIVATED 
Z NAME OF THc NEW SUBTASK AND POINTER TO PROJECT PLANS 

3 SUDTASK LIBRARY RESTORED TO INTERRUPTION TIME STATUS. 

ONE EXCEPTION 13 IF A JOJ WAS LEFT Il>i EXECUTION AT THE 
TIME OF INTERRUPTION AND IS NOW INACTIVE. IN SUCH A 
CASE, THE NEW STATUS wi_L ACCOUNT FUR THE iNTERIi''' 
ACTIVITY. 

'+ SUBTASK LIBRARY INITIALIZED CONSISTENTLY WITH THE 
PROJECT PLANS. 

3 EXPLANATION OF AUDIFiONAL CHECK INFORMATION REQUIRED 
6 ADDITIONS TO THE STl SET U^ 


***‘>-* CROSS REFERENCED TRANSITIONS 


STATE IS ACCESSIBLE FROM 

£ . A U . rj 

U.C 

V .0 
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STATE 

F.A 

F,3 


LEVEL 2 

COMPONENTS OF STATE F 
SU8TASK COMMAND MODE 



STATE DESCRIPTIONS 


LONG NAME AND TEXT 


REQUEST USER INPUT AND INTERPRET COMMAND 

THE SySTEM WILL PROMPT THE USER TO GIVE A COMMAND. 
AFTER READING IT, IT HILL bE INTERPRETED TO DETERMINE 
WHAT ACTION ME DESIRES. THE COMMAND SYNTAX WILL BE 
DELT WITH ONlY TO THE LEVtL NECESSARY TO DETERMINE THE 
BASIC INTENT AND SEPARATE OUT ANY INFuRMA TION t E . G . ARG- 
UMENTS) FDR THE IFAD UTILITY. 


0£-ACriVATt SUSTASK STEP 

THIS IS AN ALTERNATE ENTRY POINT TO 3E USED WHEN 
A PAUSE HAS BEEN GIVrN, FOLLOWED BY A COMMAND OTHER 
THAN GO, A PUSH-DOWN STACK WILL HAVE TO BE KEPT TO 
•INSURE A LAST-IN-FIRST-UUT PROCESSING ORDER. 


RE-ACTIVATE SUBTASK STEP 

THE PJSH-ODWN STACK OF INTERRUPTED SUBTASK STEPS 
MUST Oe INTERROGATED TO LOCATE THE STEP WHICH IS TO BE 
ACTIVATE'D. 
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F 1 SUBTASK COMMAND MODE 
(CONTINUED) 


ALLOHEO T'^ANSITIONS 


FROM STATS. - 

• ■ TO -STATE . ■ „ 

, .. .input-/ 

OUTPUT / 

(f» = ENTRIT) 

U = EXIT) 

CONDITION 

RESULT 

fF. A 

F « A . . t - . 

31 

8 ■ . - 


F.C 

4 

4 


t* G » A 

& 

6 


.f*H.,A ‘ ’ 

7 

e 


r*T . A 

8 

e 


t*K, A 

"liQ . ! 

F 



: Cli2j..- 

7 ■. :f 



.'.■13, . 

, '> 


<*p . A . r 

. : .1.4 . i . 



>*Q.:A 

• . ■ i5 / ' 

--.-f 


t*T . A ' , ■ ! ; 

. S t!- I T 

..1 


r*U . A 

2 

2 


r*V. A 

3 

3 


■ r*-W ;-A ' „ ' ■ 

... 17 

t . , 

l♦F. 8 

F. A 

5 

F 

-F , C * 

, l*G "i - , ... < , J ^ 

.■ ’ . 1:8 . . )- 

7 


f* H 1 - 

19 . ■ . ■■ 

7 


.1*1- 

. i i,?^0 .... 

. : -i 7 


■ -t^ K - ■ . . ■ I ' 

' . - i2‘2 . ‘ 

■ . ■ -.7. 


t>M 

24 

7 


f»N 

25 

7 


• f*0 

2& 

7 


r»P 

27 

7 


- - 'f*Q' 

28 

7 


VW • 

. . 30' 

t -■ >. -7 


* i 


* Since these are transitions to interrupted states, the 
node names at level 2 cannot be specified. 
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LEVEL 2 


TRANSITION DIAGRAM 


STATE F : SUBTASK COMMAND MODE 



















F t SU9TASK COMMAND MODE 
(CONTINUED) 


INPUT / CONDITiuN LIST 


NUMBER TEXT 

i bTOP 
i auiT 

i Terminate 

^ RETURN 

5 REGOVEkY information F.IJ-1 SU3TASK STEP Rt lLOUT RECC’D, 
OLD PUSH-DONN STACK 

6 HEi.? 

7 search 

3 ENTER DATA 

Ij modify data 

IE CONSTRUCT JOG 
iJ EXECUTE 
14 display 
uISPJSC 
17 DEFINE 

13 PuSH-uUrtN STACK WITH STATE C OH TOP 

19 PU3H-UOWN STACK WITH STATE ri ON TCP 

21 PUSri~OOrt.\« STACK WITH STATE I ON TOP 

21 PUSH-DOWN STACK WITH STATE J ON TOP 

22 PUSh-UOWN STACK WITH STATE K ON TOP 

23 FUSH-OOWFS STACK WITH STATE L ON TOP 

2h push-down STACK WITH STATE M UN TOP 

25 PUSH-DOwM STACK WITH STATE N Oft TOP 

25 PUSH-DOWN STACK WITH STATE 0 ON TOP 

27 PUSH-DOWN STACK WITH STATc. P ON TOP 

23 PUSH-DOWN STACK WITH STAT- U ON TOP 

3j PUSH-DOWN STACK WITH STATE w ON TOP 

51 IT4GORRECT COMMA >40 FO.RMaT 


UUTPJT / RESULT lIST 


NUMBER TEXT 

1 POI 4TLRS TO SUBTASK ST£^ TO f3E TERMINATED 

2 
5 

4 PUSH-DOWN STACK 

5 MODIFIED POSH-DOWN STACK, AND THE DE-AGT I VATEO STS 
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ORIGINAL PAGE IS 

F : SU3TA3K COMMAND rlOOE POOR QUALTITfl - 

(CONTINUED) 


***** CUTPJT / RESULT LIST (CONTINUED) ***** 


NUM3ER TEXT 

6 GUMMANO BROKEN UP INTO THE 3ASIC COMPONENTS 

7 last recoroeo line sent to the Terminal tefore 

THE INTERRUPTION IS kE-ISSUED TO THE T-RMIMAl; ALSO THE 
MO'JlFIEu POSH DOWN STACK. 
i EXPLANATION OP THE E<RJi, RtQUEST FOR RETRY 

/ 


CROSS KEFERE.NCEJ TRANSITIONS ***** 


STATE IS ACCbSSIaLE FROM 


r . A E . 3 

G; * h 

G. I 

H. C 
H.D 
H. E 

« 1.0 
K.O 
M.A 
M.C 
H.C 
P. J 

P. E 

U. . C 

u.o 

G. L 

Q . F 

Q . 

U.H 

(i.I 

sM . 0 

a.K 

T.d 

w.c 
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STATE 
G • A 

G.a 

G«c 

G. J 
G.t 


LEVEL 2 

COMPONENTS OF STATE G 
LEARNING ABOUT IPAD 


***** STATE OESCRIPTIONS ***** 

\ 


LONG NAME AND TEXT 


validate :J3ER 

THE USER MOST. 3£ VAlIOATEO FOR THt PROGRAHNEO 
COURSE OF INSTRUCTION HZ WANTS TO BEGIN DR CONTINUE. 
COMPLETE COURSES COVERI 'JG DIFFERENT SUBJECTS WJuL b£ 
OFFERED. A PARTICULAR SJRJsiCT MAY QE COVERED AT SEVERAL 
LEVELS OF OETAIL. 


RETRIEVE STUCENT RECORD 

USER p>ROFXlc 1 MFOrRATIUN iS MAINTAINED IN THE SY5- 
TEM SECURITY FILE. A R-ECORl IS KEPT OF EACH USERS LEVEL 
OF PROFICIENCY BASED CN GRADES FOR COURSES COMPlETEI 
AND HIS dynamic USE OF THE TEACHING FACILITY WHIlE HE 
H ORKS. 


ESTABLISH STUDENT RECORD 

IF THIS IS A FIRST REjUtST FOR HELP OR FOFs A PRO' 
GRAHMEO COURSE A STUDENT RECORD IS ESTAO'L ISHEU FOR THE 
USER. 


RETRIEVE lEsSOM PLAN 

THE SCENARIO FOR ThE PROPER LESSON IS OBTAINED FOR 
USE IN PRESENTING THE MATERIAL TO THE USER, 


PRESENT L_SSON 


THE MATERIAL 
DETERMINED BY THE 


IS PRESENTED TO THE USER AT 
USERS ABILITY TO LEAkN. 


A 


RATE 
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ORIGINAL PAGE Ih 

G * LEARNING ABOUT IPAD OE POOR QUALITY 

(CONTINUED) 


***** STATE DESCRIPTIONS (CONTINUED) ***** 


STATE LONG NAME AMD TEXT 


G.F DETERMINE CONTEXT 

THE USER HAS MADE A REQUEST FOR HELP, HE IS EITHER 
BETWEEN ACTIVITIES OR HE HAS INTERRUPTED HIMSELF TO GET 
assistance, in the latter case the system will ATTEMPT 
TO DETERMINE mHAT TYPE DF SCENARIO IS MOST Ll.KELY TO 
SATISFlf HIS NEEDS WITHOUT BEING TOLD DIRECTLf. IF THE 
USER IS BErWEEN ACTIVITIES OR THE CONTEXT OF HIS PREV- 
IOUS ACTIVITY DOES NOT PROVIDE A GOOD 3UESS, THE SYSTEH 
AND USER ENGAGE IN A DIALOGUE TU uETERmINE THE TYPE OF 
HELP He WANTS. 


G.3 RETRIEVE SCENARIO 

A SCENARIO TO GUIO-I A HELP SESSI0^4 IS RETRIEVED. 
THIS help is NOT PROGRAMMED TEACHING BUT QUERY -ANS wER, 
DISPLAYS OF OPTIONS, ETC. 


G.H SELECT LANGUAGE LEVEL 

THE USER RECORD IS USED TO SELECT A LANGUAGE LEVEL 
COMPATIBLE WITH THE USERS PROFICIENCY, THE USER MAY 
CHANGE LANGUAGE LEVEL AT ANY TIME. 


G,I respond TO USER QUERIES 

THE HELP SESSION IS A DIALOGUE BETWEEN THE USER 
AND THE SYSTEM. 
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G I LEARNING ABOUT IPAD 
(GONTINUEO) 


***** ALLOWED TRANSITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

= ENTRY) 

(,* = EXIT) 

OONDITION 

RESULT 

i*G • A 

G.A 

1 

i 


6.3 

E 

2 

G ,B 

G »C 

11 

2 


G . 0 

3 

* V 


G . G 

IT 

2 

G •v/ 

G.O 

3 ■ 

2 


G . G 

10 

2 

G .0 

G.O 

A 

■%j 


G.E 

5' 

c 

G * E 

<*F.A 

7 

2 


G.E 

& 

3 

i*b *F 

G . Q 

9 

2 


G .F 

G 

5 

1-1 

G . G 

IZ 

2 

G « j 

G . ri 

13 

2 

G ,H 

G . H 

16 



G.I 

l4- 

i. - 

G • 1 

.♦F.A 

19 

2 


G .F 

17 

2 


G.H ■ 

15 

2 


G.I 

la 

5 


m 





G I LEARNING ABOUT IRAQ 
(CONTINUEO) 



NUMBER TEXT 

1 USER NOT \/ALIDAT£Q FOR PROGRAMMED COURSE 

i USER VALIDATED 

3 USER TRAINING RECORDS AVAILABLE 

4 USER/SYSTE-J OIALOGUE RELATIVt TO LESSON SELECTION 

Incomplete 

5 LESSON SCENARIO IN USER FORKING AREA 

t> lesson session lNCOMPLir.TE 

7 LESSON SESSION COMPLETE 

A MORE INFORMA riCN REauixEu TO DETERMINE TYPE OF HElF 
WANTED 

) INITIAL HElP CONTEXT DETERMInEu 

1-j USER PROFIo.lENOY OATA AVAILAolE' 

11 ■ SET UP NEW USER USE^ TRAINING RECORD 

12 SECON’D ANO LATER HELP CONTEXT UETERMINEO 

13 MElP SCENARIO RETRIEVED SUITABLE FOR SELECTEO CONTEXT 

14 LANGUAGt level SELECTEO 

15 USER DESIRES CHANGE IN LANGUAGE LEVEL 

io USER/SYSTEN DIALOGUE R£_ATIVt TO LANGUAGE CHANGE 

iNCOMPuETE 

17 USER WANTS TO CHANGE HElP SONTcXT 

ID USER/SYST-E.1 HELP DlAuCSJE INCOMPLETE 

15 help COMPLETE 


OUTPUT / RESJLT lTST 

NUMBER TEXT 

1 MESSAGE TO SElEGT ANOThEtl COURSE OR TERMINATE 
> - 

3 MESSAGE TO USER INFORMING HIM TO PROCEED 

CROSS REFERENCED IRANSITIGNS 

STATE IS ACCESSIBLE FROM 

G • A i* o A 
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STATE 

H.3 


H.T 

H.£ 


OEIGlNAIi 

LEVEL 2 OF. POOR QUALITH 

COMPONENTS OF STATE H 
SEARCHING THROUGH THE LIBRARIES 


STATE OESGRIPTIOWS >>■**** 


LONG NAHc AND TEXT 


lNTER=>RtT GCMi-lAND 

THE J3ER PAY Wl'Sh TO CONTROL HIS OWN SEARCH bY 
SCANNING OICTiONARY AND DIRECTORY tNTRIES TO IDENTIFY 
library ENTRIES JO JE DISFLAVED. HE MAY ALSO WANT THE 
SYSTEM TO PERFORM SEARCHES UTILIZING SELECTION CRITERIA 
HE SUP'^LIES. 


■ USER CONTROLLED SEARCH 

A SEARCH FOR A SPECIFIC JlCTIONARY, DIRECTORY, OR 
LIBRARY ExlTRY MAY BE MAJE, OR THE USER HAY PAGE THROUGH 
AN ENTIRE OICTIONARY OR DiRECTORY. 


SYSTEM COMTRCLLEO SEARCH 

AN INFORMATION ^ELECTION E X PRESS IC N“IS GIVEN TO 
THE SYSTEM AND JShO TO CONTROu THE SEARCH. 


DISPLAY SELECTED INFORMATION 

INFORHATICN IDENTIFIED 3Y A SEARCH IS DISPLAYED 
TO THE USER FOLLOWING VALIDATION FOR READ ACCESS. 
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H t SEARCHING THROUGH THE LIBRARIES 
(GONTINUEO) 



ALLOWEO TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(.♦ = ENTRY) 

(t* = EXI D 

CONDITION 

RESULT 

r»H.3 

H,B 

■? 

L- 

2 


H ,C 

k 

4 


H .0 

9 

4 

ri.C 

. r»F.A 

li 

1 


H.C 

5 

2 


H.'E 

6 

1 

H.D 

r*F.A 

11 

1 


■ H.D 

5 

2 


H.E 

6 

•1 

H .E 

-»F.A 

11 

■ 1 


H • C 

7 

1 


H.O 

IJ 

1 


H.E 

5 

2 
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H I SEARCHING THROUGH THE LIBRARIES 
(CONTINUED) 


***** input / CONDITION LIST ***** 


NUMBER TEXT 

B MORE INFORMATION REQUIRED TO COMPLETE COMMAND ANALYSIS 
L COMMAND ANALYSIS COMPLETE, USER CONTROLLED SEAFCH 
U ESI RED * 

5 ADDITIONAL USER INPUT REQUIRED 

6 UATA FOR DISPLAif LOCATED 

7 USER signal TO START NE ^ USER CONTROLLED SEARCH 

3 COMMAND ANALYSIS COMPLETE, SYSTEM CONTROLLED SEARCH 
Desired * 

11 USER signal to START NEW SYSTEM CONTROLLED SEkROH 
11 USER SIGNAi. THAT HE HAS COMPLETED HIS ACTIVITY 


OUTPUT / RESULT lIST 


NUMDEK TEXT 

1 MESSAGE INFORMING USER TO f'ROCEEO 

2 MESSAGE REQUESTING USER TC ENTER MORE INFORMATION 
L PARSED COMMAND AND COMMAND CONTROL TABLE 


***** CROSS REFERENCtD TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 

H.3 F.A 

F.A.O 
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STATE 
I. A 

1.3 

I.C 

I. J 


ORIGINAL PAGE IS 
level 2 POOR QUALITY 

COMPONENTS OF STATE I 
CHEATING LIBRARY ENTRIES 


***** STATE DESCRIPTIONS ***** 


LONG NAME ANO TEXT 


INTERPRET COMMAND 

THE USER MAY ENTER DATA TO 3UIL.D A NEW LIBRARY 
ENTRY. THIS HAY BE AN INSTANCE OF A SYSTEM JaTA STPJCT- 
URE SUCH AS A COOING MOOdL: OR A STORED DATA DEFIMT- 
I ON . THE DATA ENTERED MAY AlSO B£ VALUES WHICH COMPRISE 
AN INSTANCE OF A USER DEFINED JATA SET. 


validate user 

THE USER h-JST HAVE PERMISSION TG ENTER c>ARTICUuAR 
TYPfcS OF 'DATA INTO THE Cl OR HIS STl. 


CONSTRUCT LIBRARY ENTRY 

A complete, new library £NT:^Y(DIRECT0RY ANO TEXT) 
IS CONSTRUCTED. A DICTIONARY ENTRY, IF REQUIRED, IS 
ALSO MADE. 


DISCONNECT jSER FROM DATA 


ASS 



I * CRIATING library ENTRIES 
(CONTINUED) 


ALLOWED TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

( 1* = E N T i<y ) 

It 

m 

X 

-H 

CONDITION 

RESULT 

t*l .A 

I .A 

1 

1 


1.6 

2 

2 

I . i 

I.B 

4 

H 


l.C 

5 

9 

I .0 

I.B 

ii 

U 


- l.C 

i'j 

i 


I.-O 

6 

c 

I .J 

. ,*F.A 

7 



transition diagram 


ORIGINAL PAGE IS 
OF POOR quality 


I J CREATING LIBRARY ENTRIES 
(CONTINUED) 


INPUT / CGNUlTIOri LIST ***** . 


NUMDcR TEXT 

1 MORE INFORHATION REaUiREQ TO COMPLETE COMMAND ANALTilS 
a COMMANO ANALYSIS COMPLETE 
H USER NOT PERMITTED REOU£:>TEJ ACTION 

5 USER validated FOR REOU-ZSTEG ACTION 

6 LITRARY entry CONSTRUCTION COMPLETE 

7 USER DISCONNECTED FROM ll 

11 LIBRARY ENTRY CONSTRUCTION INCOMPLETE 

ii hOOITICNmL validation RERJIRED FOR DERIVATIVE ACTIVITY 


***** OUTPUT / RESULT LIST ***** 


NUMBER TtXT 

1 MtSSAGE RE lUESTIivG USER TO SUPPLY MORE IFfFCRMAT'ION 
R PARSED COHMANJ ANU COHMANU CONTROL TAbLE 

MESSAGE INFORMING USER OF LACK OF VALIDATION. A3K FOR 

ALTERNATE REOUEST FROM HI Mr. 

5 LE IN USER WORKING AREA 
G U£ AVaILADuE in DATA BASE 
3 
iJ 


+ CROSS REFERENCtO TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 

I.A ’ F.A 
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LEVEL 2 

COMPONENT^ OF STATE K 
MODIFYING LIBRA.-^Y ENTRIES 


STATE 


K.A 


■K, J 
K.O 


K. J 


STATE DESCRIPTIONS + 

long name ano text 

OUNNECT USER WITH DATA TO -'E HGuIFIEL- 
PhRFORM i-nOlFo-CATiONS WITH DIALOG 
UPDATE OIRECTORY ENTRY 
0I5C0NNECT bStP FROM DATA 


***=f-* ALLOWED TRANSITIONS 


FR0 1 .STATE 

TO ST A T t 

INPUT / 

OUTPUT 

(r» = ENTFIY) 

(>* = !lXIT> 

condition 

RESULT 

• A 

K.A 

1 

1 


K.a 

2 

2 

K.-3 

K.8 

6 

A 

X 


<.c 

A- 

A 

K.C . 

K.U 

7 

b 

K.D 

i*F.A 

G 

7 
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A39 


K t HOOIPyiNG tI8RA:<f ENTRIES 
(CONTINUED) 


INPUT / CONDITION LIST ***^>>- 


NUN3ER TEXT 

1 IDENTIFYING AND LOCATING INFORMATION INCOMPLETE 

2 LIdRARY ENTRY TO BE MODIFIED EXISTS AND USER IS \/ALlJ- 
ATEO TO PERFORM MOOIFIC AT IONS 

4 MODIFICATION DONPLETED 

5 MODIFICATIONS INCOMPLETE 

7 DIRECTORY ENTRY UPDATE COMPLETE 
j USER IS DISCONNECTED FROM DATA 


OUTPUT / result list 


NUMOER 


TEXT 


1 

2 

4 

•3 

7 


MESSAGE ISSUED TO USER REDJESTING ADDITIONAL INFORM- 
ATION 

USER IS CONNECTED TO LI3RAP-.Y ENTRY 
UPDATED L£ TEXT IN USER AREA 
UPDATED lE ATTACHED TO USER 
UPDATED LE AVAILABLE IN DATA BASE 


CROSS REFERENCED TRANSITIONS >***** 

STATE IS ACCESSIBLE FROM 

K. A F.A 
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LEVEL 2 

COMPONENTS OF STATE H 
CONSTRUCTING A JOB 


ORIGINAU PAG® ffil 
OF POOR QUAIOT 


STATE 

n.x 

P . 3 
H.C 


STATE OESGRIFTIONS 


lONu. nIANE ANJ TEXT 


OETER-iiNc. Available job cohponents 

TAKT THE USERS LIST Or 0-)S AND FlNJ OUT HOW MANf 
ARE CURkENTlY DEFINEO A 'Ij ACCESSABLE ANJ HCi^ MANY AR- 
VET TO BE OEFIUED. TdE JSER MAY THEN GHJOSE TO 
CONSTRUCT THE GM3 OR NOT 


CONSTRUCT AN ON LIdRARY ENTRY 


CONSTRUCT A J08 LIBRARY ENTRY 




ALlOhED 

TRANSITIONS 


FROM 

STATE 

TO STATE 

INPUT / 

OUTPUT 

(i* = 

ENTRY) 

{f = E 

XIT) 

CONOITION 

RESULT 

r*H . A 


-♦F.A 


6 




M..B 


1 

4 



M.C 


2 

3 



M.A 


3 

1 



M.3 


9 

e 



H.C 


2 

5 



M.C 




M .C 


r»F.A 


k 

2 



M.A 


5 

5 



H .8 


7 

7 



H.C 


13 

9 
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M I CONSTRUCTING A JOS 
(GONTINUEO) 


OBIGINAU PAGE II 
OP POOR QUALITY 


INPUT / CONDITION LIST 


NUH-3ER ' T£KT 

i OM OIRECTORT INDICATING ThAT AT LEAST 0 JC REQUIRED DM 
IS UNDEFINED AND/OR INAOCESSADLE Am AN INDICATION FROM 
THE USER THAT HE DESIRES TO CONSTRUCT THE CM(S) ' 

Z OM DIRECTORY INDICATING THAT ALL REQUIRED OMS ARE 
DEFINED AND ACCESSASlE. 

S NON-EMPTY LIST OF OMS TO BE DEFINED 

4 EMPTY LIST OF JOdS TO Usl DEFINEU 

5 NON-EMPTY LIST OF JOSS TO S£ -DEFINED 

5 OM DIRECTORY INDICATING THAf AT LEAST ONE REQUIRED OH 
IS UNDEFINED AND/OR INACCESSA3LE AND AN INOICATDN FROM 
THE USER THAT HE DOES NOT WANT TO CONST -iLrCT THE DM. 

/ USERS INDICATION THAT ONE DR TORE OMS MUST 3E DEFNEJ 

d ENTRY FLAG FROM M.C AND ALSO INPUT NO. E 

0 OM CONSTRUCTION INFORMATION WHICH MUST COME FROM THE 
USER 

IJ JO>3 CONSTRUCTION INFORMATlOiN WHICH MUST COME FROM THE 
USER 


OUTPUT / RESULT LIST 


numdek text 

1 ONE OR MURE NEWLY DEFINEu CMS IN THE STL AND THE 
LIST OF UNDEFINED OilS 

^ JOD DEFINITIONS COMPLETED IN THE STL 

3' complete list of OM NAMES BY LISRARY 

list of names F0UND(3Y ^IjRARY) , AND THOSE YET TO BE 
FOUND 

5 LIST OF UOdS yet TO DE UEFINLO 

-3 — 

7 OM NAME (3) 

d PROMPTS FROM THE SYSTEM FOR THE PROPEFs DM CONSTRUCTION 
INFORMATION 

3 PROMPTS from THE SYSTEM FOR THE PROPER JCO CONSTRUCTION 
INFORMATION 

CROSS REFERENCE-D TSANSiTIONS ***** 


■' STATE IS ACCESSISlE FROM 


-M. A 


F.A 
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STATE 
N ,A 

NJ. 3 
N.J 

M.3 

M.E 


LEVEL 2 

COMPONENTS OF STATE N 
EXECUTING A JOB 


STATE OESCiilPTIONS ***** 


LONG NAME ANO TEXT 


ESTABi-ISH THE REU'JIREO LtN LIST 

SCAN THE JOb SPECIFICATIONS FOR ALi. INPUT/OUTFJT 
lEi ANO NITH THE QUALIFYING INFORMATICN GIVEN WITH THE 
EXCCUTXGN COMMA vlO, ESTA3LISH THE LIST OF NAMES FOP 
SEARCHING IN THE LIBRARIES. 


CHECK FOR LuN IN LIBRARIES 
LOOK FOR THE LEN IN THE STL ANO THEN IN THE CL. 


PREPARF. J D3 FOR EXECUTION 

THE SKELETON OF THE JOB OEFINITICN MUST NON BE 
FILLEO IN «ITH ITEMS PERTINENT TO THIS EXECUTION. THE 
EXECUTABLE COOF FILES MUST BE SET UP PROPERLY, ANO THE 
CONTROL CAROS FOR THIS EXECUTION MUST BE GENERATED. 


INITIATE EXECUTION 


SUBTASK STEP EXECUTING 

THIS REPRESENTS THE STATE OF THE SYSTEM WHEN THE 
JOB IS EXECUTING ANO NOT COMHUNICATINu. WITH THE' USER. 


***** ALLOWED TRANSITIONS ***** 


FROM STAIE 
{.* = ENTRY) 


TO state input / 

(:♦ = EXIT) CONDITION 


OUTPUT / 
RESULT 


!*N. A 
N • 3 


N.d 
N.3 
N .C 
N.O 
N.E 
f*0 .A 
r»0 .G 


1 

7 

Z 

3 

A 

5 

6 


1 

7 

2 

5 

6 
4 
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N .0 
N.O 
i*N , E 




N t EXECUTING A JOB 
(CONTINUEO) 


INPUT / CONDiTICN LIST 


NUM3ER TtXT 

i LIST OF ULEN FRON J03 OESSRIPTION AND UUALIFTING 
INFORMATION FROM THE EXECUTION REQUEST. 

Z STL, CL DiRcCTCRIES CGNTAInING All REQUIRED LEN WITH 
PROPER ACCESS COUES 

3 STATUS complete ON ALL JOD COMPONENT FIlES 
A INOIGATUR FROM THE OS THAT THE STS IS EXECUTING 

5 IN-^UT request COMMANj F^Ch THE STS 

S OUTPUT COMMAND FROM THE STS 

7 STu, Cl DIRECTORIES LACRIMG SOME OF Tht LEN 


OUTPUT / RESULT l 1ST + 


NUH3ER TEXT 

1 LIST OF ALL LEN REQUiftED FOR TnE JOB 

2 LINKAGE ESTAULlSHED TO ALl RtaUXRED L£ 

3 EXECUTABLE CODE F1lE(S) , CONTROL CARD STREAM 

A TERMINAL INPUT REQUEST 

5 TERMINAL OUTPUT REUUtST 

S 

7 EXPLANATION TO THE USER, REQUEST FOR ADDITIONAL 
information TC use- in locating the missing LEN 


CRJ55 REFERENCE) IRANSITIUNS 

STATE IS AGCESSIbLE FRO -1 

N . A F ♦ A 

N.E O.G 
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STATE 
O.A 
0 . -3 

0 . c 


LEVEL 2 

C0MPDNENT5 OF STATE 0 
COMMUNICATING vJITH A JOO 




***‘^>|■ STATE OESC-il-TICNS *»»»» 

LONG NAME AND TEXT 
SU3TA3K STEP KETUESTING USER INPUT 

SU3TASK 3Tt? PROCESSING USER INPUT 

WORK NECESSARY TG INTERPRET THE INPUT ANO CORRECT 
ANY Errors , 

S'JOTASK CTE- OUTPUTTING INFORMATION 


ALLOWEJ TRANSITIONS 


FROM STATE 
(.♦ = ENTRY) 


TO STATE 
(<* = EXIT) 


INPUT / 
COHOITION 


OUTPUT / 
RESUx-T 


f*0 • A 
0.3 

t* 0 . !J 


0 . B 
0 .A 
O.C 

.E 

O.A 


1 

2 

2 

4 

J 


1 

t; 

2 

4 

3 
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0 * COMMUNICATING WITH A JOB 
(GONTINUEO) 




***** input y CONOiTION LIST ***** 


NUMBER - TEXT 

1 USER INPUT LINE TO STS 

2 INPUT COMMAND FROM STS 

6 END OF OUTPUT INDICATOR 

A GOMPLEThO INPUT FROM USER 


**-v-^* OUTPUT / RFSJLT ulSl ***** 


NUMBER . TEXT 

1 TERMINAL LINE 

2 RE-aueST FOR MORE InPjT 

S i OR MORE lines TO T;::RHHAL, INPUT RE-^UEST 

■-+ optional acknowleogemlnt of input RECE1\/ED correctly 


***** CROSS REFERENClO TRANSITIONS ***** 


STATE 

IS ACCESSIdLE 

0. A 

N.E 


N.E . A 

O.C 

N.E 


N • E • w 


I 
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level e 

COMPONENTS OF STATE P 
DISPLAYING USULTS 


STATE 

P.A 

P. J 

P.C 

r .0 
P.E 


STATE DESCRIPTIONS 


long NAriE AND TEXT 


INTERPRET DISPLAY REQUEST 

ANALYZE THE DISPLAY REQUEST TC DETERMINE THE LE 
AND lV involved AND REUJ-ST THE jELECTFON CRITERION 


evaluate SELECTION CRITERIA 

ANALYZE IhE CRITERIA FOR SELECTING DATA TO DE 
displayed and FOKH the analytical EXPRESSION 


ESTABLISH SOPER-SET INFORMATION 

FETCH INFORMATION REQUIRED FOR THE SELECTIOf^ ANT 
IF THE selection EXPRESSION IS NOT IN THE TERMS OF THE 
RAW INFCSMATICN, TRANSFORM IT PRIOR TO APPLYING THE 
selection CRITERIA 


SELECT PROPER SUB- SET INFORMATION 


APPLY THE 
INFORMATION TO 


SELEGTIOQ CRITERIA TO THE SUPER-SET 
ESTABLISH THE JtSIREU SUBSET INFORMATION 


display REQUESTED INFORMATION 
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P * 0I3PLAYIMG RESULTS 
(CONTINUED ) 


ALLOWED TRANSITIONS 


FRON STATE 

TO STATE 

INPUT / 

OUTPUT / 

(r» = ENTRY) 

(.♦ = EXIT) 

CONDITION 

result 

r»P.A 

P,A 

3 

-3 


P.B 

1 

1 

P .3 

P .C 

2 

2 

? .0 

>*F »A 

11 

11 


P,C 

i-3 

iC 


P .0 

5 

0 

P, J 

-♦F . A 

S 

c 


P.C 

5 

r 


P • £ 

4 

4 

P .E 

=»F .A 

7 

• ■ 7 


P.A 

6 

fc 
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P * DISPLAYING RLSJLTS 
{CONTINUED) 


INPUT / CONDITION LIST 


NUMBER TEXT 

1 properly FORMATTED OISPlAY REQUEST 

2 SUFFICIENT INFORMATION To ESTACuISH A SELCTiOO CRITERIA 

3 PART OR All OF THE SJPlR3=.T INFORMATION FROM THE - 
LIBRARY 

‘t EMPTY SEARCH TA JLE 

5 NON-EMPTY SEARCH TABLE 

6 USER REQUEST FOR MORE OISPlAY 

7 USER TERMINATION CODE 

3 USER INDICATOR THAT HE DOES ITOT HANT THE INFORMATION 
displayed (THIS IMPLIES THAT HE IS ONLY INTERESTED IN 
knowing THAT THE INFORMATION EXISTS) 

3 IMPROPER OR INSUFFICIENT INFORMATION FOR THE SELECTION 
CRITERIA 

i) LlN REUUIREO FOR THE SEARCH ARE NOT ACCESSA3LE BY THIS 
USER 

li USERS OOMMANO TO EXIT 


OUTPUT / RE5JLT lIST 


NUMBER TEXT 

1 FORMAL EXPRESSION OF DISPLAY REQUEST 

2 FORMAL EXPRESSION OF SELECTION CRITERION 
J SUPER-SET INFORMATION 

=+ INFORMATION TC BE DISPLAYED 
B REMAINING SEARCH lIST 

0 - 

7 

1 

3 EXPLANATION OF ERROR, RERUtST FOR CORRECTION/ ADOITION 
IT ERROR MESSAGE TO USER, WAIT FOR A RESOLUTION OR USERS 

COMMAND TO EXIT 
ii 


CROSS REFERENCE J. TRANSITIONS ->-*-^** 


STATE IS ACCESSIBLE FRO 1 

P.A F.A 

i“ • A * 0 
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STATE 
G .A 

Q. 3 


Q.3 
Q.3 
Q • E 
Q.F 
Q.'i 
O.H 


LEVEL 2 

COMPONENTS OF STATE Q 
DISPOSITION OF lITRARY ENTRIES 


****•>■ bilATE DESCRIPTIONS 

long name and TEXl 


INTERPRET GGi-IHANu 

THE CJMMANJ is ANALYZED TO DETERMINE WHICH TYPE Oh 
ACTION iS TO EE PERFORMED. lITRARY ENTRIES HAY J£ 

purged, moved to anj from archive storage, moved from 

STl to STi., STL TO Cl, CL TO STL, AND FROM CL OR STl 
TO A LiiSTINATlON OUTilDE CF IPAD. 


validate user for activity 

VALIDATION REQUIRES PERMISSION TO PERFORM DESIRED 
ACTION mS WEL- as PERMISSION TO ACCESS THE DATA WHICH 
IS REFERENCED. 

ACTIVITY VALIDATION FOR THE ACTIVE USER IS OGNE 
HERE. ADDITIONAL VALIDATION MAY DE REQJXkEO FCF THE RE- 
GIPIcNT of DATA WHICH IS MU.VEU FROM AN STL TO ANOTHER 
STl, or TO A NCN-IPAO DESTINATION, THE SAME IS TRUE FOR 
DATA RESIDING IN THt Cl, A SPECIAL CLASS OF NON-IPAD 
USERS ELIGIBLE TO RECEIVl IPAD CONTROLLED DATA HAVE 
validation INFORMATION IN THE SYSTEM SECURITY FILE. 


PURGE A Cl ENTRY 
PURGE A STl ENTRY 
MOVE F-cDH ARCHIVE TO CL 
MOVE FROM CL TO ARCHIVE 
MOVE F<OM STL TO Gl 
MOVE FROM CL TO STL 
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ORIGINAL PAGE Th 
OF POOR QUALITY 


Q I DISPOSITION OF LIBRARY ENTRIES 
YCONTINUED) 


STATE DESCRIPTIONS (CONTINUED) 


STATE 


Q.I 


Q. J 


Q.< 


LONG MANE AND TEXT 
MOVE FROM STL TO STL 
MOVE FROM STL OUT OF IPAD 
MOVE FROM CL GUI OF IPAD 


allowed IRANSITIONS 


FRO J STATE 

TO STATE 

INPUT / 

OUTP! 

(r» = ENTRY) 

(t» = EXIT) 

CONDITION' 

RESU 

i*Q« A 

Q,. A 

1 

1 


3.8 

3 

5 

a.B 

(D.C 

5 

a 


Q.O 

6 

5 


U.E 

7 

5 


3.F 

a 

5 


3.G 

g 

5 


3.H 

la 

5 


3.1 

11 

c 


Q.J 

12 

5 


Q . K 

13 

5 

Q • fj 

r^F.A 

15 

5 

a .3 

r*F,A 

15 

5 

Q.E 

r^F.A 

15 

5 

Q.F 

r*F.A 

1 5 


3 • b 

^F.A 

15 

5 

Q.H 

.A 

15 

c 

a. I 

(♦F .A 

15 

5 

Q»J 

f*F.A 

15 

5 

iX.K 

■*F.A 

15 

5 


ASS 






Q t DISPOSITION OF LIBRARY ENTRIES 
(CONTINUED) 


***^^ INPUT / CONDITION LIST 


NUMBER 


TEXT 


i 

3 

5 

6 
7 
3 
■i 

10 

11 

12 

13 

15 


MORE INFORMATION REOUIRED TO COMPLETE C 
COMMAND ANALYSIS COMPLETE 


USER VALIDATED FOR 
USER VALIOATEO FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
USER VALIDATED FOR 
OISPOSITlOr4 COMPLET 


Gi- PURGE 
STL PURGE 

MOVE ARCHIVE TO CL 
MOVE CL TO ARCHIVE 
•lOVE STl to STL 
HOVE CL TO STL 
MOVE STL TO STL 
MOVE STL OUT OF IPAD 
MOVE Cl out OF IPAD 


OMMANO ANALYSIS 


OUTPUT / RESULT LIST 


NUMBER TEXT 

1 MESSAGE REUUESTING USER TO ENTER MORE INFORMATION 
3 PARSED COMMAND AND COMMAND CONTROL TABLE ■ 

•3 MESSAGE INFORMING USER TO PROCEED 


R£FtRENCED TRANSITIONS 

STATE IS ACCESSIBLE FROM 

D.A F.A 

F « A tt D 
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LEVEL 2 

COMPONENTS OF STATE T 
SU3TASK STEP CONTROLLED ABORT 


STATE 

T.A 

T..3 


***** STATE DESCRIPTIONS ***** 


LONG NA^IE AND TEXT 


SUBTASK STEP CLEAN-UP 

LOOKING AT THE NATURE OF THE SUBTASK STEP, SEE 
NHAT L£ are AFFECTED AND MODIFY THE STL AND Cu IN 1 nE 
PROPER WAY. 


eliminate the STACK ENTRY 

PURGE THE SUBTiSK ROLLOUT FILE AND ELIMINATE THE 
TOP ENTRY IN THE PUSH OOHN STACK 


***** ALLOWED TRANSITIONS ***** 


FROM STATE 
(f = ENTRY) 


TO STAT- INPUT / OUTPUT / 

(,♦ - .EXIT) CONDITION RESULT 


r»T .A 
T .3 


t.a 

T . S 
r*F.A 


3 

1 

2 


0 

1 

2 


TRANSITION DIAGRAM 
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T 1 sllBTASK STEP C014TR0LLE0 ABORT 
(CONTINUED) 


****>^ input / GONOiriON list **‘t-** 


NUN3ER text 

1 PUSH DOWN STACK 

2 PURGE RESPONSE FROM OS 

3 AMBIGUOUS STATUS IN AN LE(THE IMPLICATIONS OF SAi/lNG OR 
PURGING THE LI ARE NOT HcLL OEFINEO) 


OUTPUT / ^lESULT LIST 


NUMBER TEXT 

1 

2 

3 EXPLANATION OF THE STATUS AND A REQUEST FUR A DECISION 
TO SAVE OR PURGE THE LEV 


CROSS REFCRENCEJ TRANSITIONS 
STATE IS ACCESSIBLE FROM 


T.A 


F.A 
F.A. B 
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STATE 

IJ.A 

u.a 

U.C 


LEVEL 2 

COMPONENTS OF STATE U 
SUBTASK INTERRUPTION 


Da 

wSf 


STATE OESGRIPTIONS 


LONG NAME ANJ TEXT 


DETERMINE EXil MODE 

DECIDE IF THE USER IS JUST INTERRUPTING OR liE ALSO 
WANTS TO CuNTiNUE EXECUTING AFTER SIGNING OFF THE SUB- 
TASK. 


PREPARE THE SUbTASK Lc FOR THE CL 

CLEAN UP FROM TmE CURRENT STATE SO THAT REGOVERf 
IS POSSIBLE AT A LATER TIME 


PREPARE FOR EXECUTION AFTER LOG-OFF 

SET d? A MACf^O PROCEDURE TO EXECUTE AFTER THE 
USER HAS OISCONNECTED FROM THIS SUbTASK. 




ALlOWEJ 1RAN3ITIONS ***** 


FROM 

STATE 

TO STATE 

INPUT / 

OUTPUT 

(t* = 

ENTRY) 

(<* = EXIT) 

CONOITION 

RESULT 

r»U. A 


U.B 

1 

1 



U.C 

2 

O 

c. 

U .H 


f»0 

3 

O 



(♦£ . A 

A 

5 

U .C 


-0 

3 

6 



f*H.A 

A 

A 


A60. 






LEVEL 2 TRANSiTION DIAGRAM 
STATE U : SUBTASK INTERRUPTION 
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U * SU3TA3K INTERRUPTIOM 
(CONTXNUEO) 


DllKjiNAL PAGE lb 
DE POOR QUALITY 


input / CONDITICN LIST /^***‘^ 


NUM3ER TEXT 

i INSTRUCTIONS TO INTERRUPT IN THE CURRENT STATE 
INSTRUCTIONS TC INITIATE EXECUTION OF A JOB OR 
CURRENTLY INTERRUPTEO SJOTASK STtP AFTER TERHINAL SION 
S OONE 
4 ANOTHER 


***^■> 1 - OUTPUT / RESULT LIST 


NUH3ER TE,Xr 


2 EXEXCUTE COMMANJ, OR A RETURN 

3 CO-1PLETEO SU0TA3K LE IN 1 HE CL, EXIT CO-^HANU TO OS 

4 MACRO PROCEDURE TG 6iL ZXHCUTEO, COMMAND TO OS TO 
EXECUTE THE MACRO -PROCEJURE PROCESSOR, COMMAND TO THE 
OS TU EXECUTE 1H£ SJ5TASK SET-UP PROCESSOR. 

5 COMPLETED SUDTA5K IN THE CLJ EXECUTION COMMAND TO 
THE OS TO EXECUTt THE 5JBTASK SET UP PROCESSOR. 

3 macro procedure to Ot EXECUTED, COMMAND TC THE OS TO 
EXECUTE THE MACRO PROCcOURH PROCESSOR, AND AN EXIT 
CUMMANO TO THE OS. 


***** CROSS REFERENCE 3 TRAMSITICnS ***** 


STATE • 15 ACCESSIBLE FRO ^ 


U.i 


F. A 
F , A . b 
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LEVEL 2 

COMPONENTS OF STATE V 
SUBTASK TERMINATION 


STATE 

V.A 

V.S 


STATE OESCRIPTIONS 


LONG NAME AND TEXT 


REPORT GENERATION 

R£PORTS(PROBABLir 3PE0IF1EU IN PLANS) NILL JE PRE- 
PARED AT THIS TIME. THIS ftiLL INCLUDE SUMMARY A ^30 
UETAILEU REPORTS. 


TABULATE IN PLAN 

ALL OF THE SUBTASK REG ORJS ( E . G'. AGCCUNTING) WHICH 
ARE TO BE KEPT WILL BE TRANSFERRED INTO THE APPROPIATE 
PLACE IN THE PLANS. THE EVENT OF SUSTASK' TERMINATION 
WILL BE TArJULATEO WHEREVER REQUIRED. 


DISPOSITION OF lE 

AUTOMATiGtVIA THE PLANS) AND MANUAL DISPOSITION GE 
THE LE f^SIJENT IN THE STL AT THIS TIME. 


****** ALLOWED TRANSITIONS *>>■*** 


FROM STATE TO STATE INPUT / OUTPUT / 

(r* = ENTRY) {& = EXIT) CONDITION RESULT 


[♦V.A 
V.B 
V .c 


V.8 

V.C 

[♦0 

[♦E.A 

V.C 


1 

2 

5 

4 

p 


2 

3 


original 
OF POOU 


QUALtl^ 
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" V, * 'SUBTASK TERMINATION 
(CONTINUED) 


INPUT / CONDITION LIST 


NUMBER TEXT 

1 ALL INFORMATION REQUIRED TO COMPLETE THE REPORTS 

2 SUBTASK ACTIVITY AND AC :OHPl.ISHME NT RECORDS 

3 DONE 

4 ANOTHER 

5 USER INDICATION THAT SOME MANUAL DISPOSITION IS NEEDED 


***** OUTPUT / result list ***** 


NUMBER TEXT 

1 ALL REPORTS SPECIFIED IN THE PLANS aND/DR ANY OTHERS 
DICTATED 3Y THE USER. 

2 ALL SUMMARY AND ACCOUNTING INFORMATION TABULATED IN THE 
PROJECT PLANS. 

3 ALi. STL RESIDENT ITEMS OIS'^'OSEU OF. 

4 REQUEST FDR ADDITIONAL DISPOSITION COMMANDS , 


***** CROSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 

V.A E.a 

E. 3.D 

F. A 
F.A.D 
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STATE 

W.A 

W.i 

W.C 


LEVEL 2 

COMPONENTS OF STATE W 
DEFINING LI&RARY ENT'^sIES OR VARIABLES 


ORIGINAi; PAGE IS 
OF POOR QUXiOT 


STATE OESCRIPTIONS ***** 


LONG 'i-A'Ac ANJ TEXT 


intekpret command 

THE COMMANU IS ANA-_YZCD TO OETEPMINt NHEThER THE 
USER INTENUS TO INPUT A ^l LmTRY FOR A DIGTIGNARf IN HIS 
STL OR IN THE CL. THE SPECIFIC OICTIGHARY AND LIBRARY 
ENTRY TYPr TO D£ OEFINtO A-E ALSO DETLRMiNEI. 


validate user 

THE USER MUST HAVE PERMISSION AND ACCESS COOES- 
THAT WILL 4 L 1 .OW HIM TO CARRY JUT HiS DESIRED ACTIONS. 


CjN STRUCT OiCTiONAKY ENTRY 
DATA FOR THE DICTIONARV ENTRY IS PROVIDED 3Y TnE 

U StR. 




ALLOWED TRANSITIONS ***** 


FROM 

STATE 

TC STATE 

INPUT / 

OUTPUT 

(.♦ = 

ENTRY) 

(t* = EXIT) 

CONUITION 

result 

.A 


W.A' 

1 

1 



W. LI 

0 

3 

W .3 


W.B 

5 

4 



w . G 

4 

7 

H .C 


fF.A 

3 

6 



W ,C 

b 

1 
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original page is 

OF POOR QUAIiini 



LEVEL 2 TRANSITION DIAGRAM 
STATE W: DEFINING LIBRARY ENTRY OR VARIABLE 
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W t DEFINING LIBRARY ENTRIES OR VARIABLES 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NU-'iecR TEXT 

1 MORE INFORMATION REQUIRED TO COMPLETE COMMAND ANALYSIS 
3 COMMAND ANALYSIS COMPLETE 
H USER VALIOATEO FOR REQUESTED ACTIVITY 
5 USER NOT PERMITTEU TO CARRY OUT THE REQUESTED ACTICJ 
o MORE INFORMATICi^ KE0UI<ED TO COMPLETE DICTIONARY ENTRY 
.3 dictionary ENTRY COMPLETE 


***** OUTPUT / <ES JLT lIST ***** 


NUMBER TEXT 

i MESSAGE requesting USER TC ENTER MORE DATA 
J PARSED COMMAND AND COMMAMO CONTROL TABLE 
A MESSAGE INDICATING RtCUESTED ACTION IS NOT VALID. 

ASK FOR ALTERNATE COMMA lU 
■3 DICTIONARY ENTRY AVAlLAiLL! IN THE DATA BASE 
7 MESSAGE INFORMING USER TO PROCEED 


***** C^DSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FRO N 


ti • A 


F . A 
F. A. 0 


OUlGJNAIi Papp tc. 
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STATE 

E.A. 

E. • A • 


LEVEL 3 

COMPONENTS OF STATE E.A 
IPAD LOG-ON 


STATE OtSC SIPHONS ***** 


LONG NAME ANJ TEXT 


USER VERIFICATION 

GIVEN A USER 10 AND- PASSWORD , VERIFY THAT 
THIS IS A VALID USER. ADDITIONAL CHECKS SEYGNO THE 
ID AND PASSWORD MAY HAVE TD BE MADE. 


SUBTA'SK VERIFICATION 

GIVEN A. SUDTASK IDENTIFIER, CHECK TO SEE THAT 
THE SUBTASK EXISTS AS A GIRECrORY TYPE lE IN THE CL 
OR AS A DEFINED ITEM IN THE PROJECT PLANS. IF THE SJ3- 
TA3K EXISTS IN THE CL, IT MUST NOT BE ACTIVE WITH 
ANOTHER USER. 



ALLOWED TRANSITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(c = ENTRY) 

<r» = EXIT) 

CONDITION 

RESULT 

(♦E . A » A 

E.A.O 

i 

1 

E.A.b 

;»£.B.A 

2 

2 


r*E.C.A 

3 

3 


0^' POOR QUAUl-^1 
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E.A t IPAO LOG-ON 
(CONTINUED) 


TRANSITION DIAGRAM 



xNPUT / CONOinciN LIST *‘>-*^* 


NUHJER TEXT 

1 VALID USC^ N’JhSCR-ACOGU'IT NUMDER PAIR. 

2 SUD-TASR IJ£NTIFIER= STN(P\) aHICH EXISTS IN THE CL 4vlJ 
IS NOT OCCUPIED 3V AhOTHER JSER.(iT,M= SJOTA3K NAME, 
PN=PR0JLCT NAME) 

.3 SU3TASK IDENTIFIER^ STN(PN) EXISTING ONLY IN THE CL 
L£ TYPE PLAN FCR PROJECT PN. 


OUTPUT / KtSJLT list ****»■ 


NUM5ER 


TEXT 


1 

7 

s 


LOCATION OF THE OIRECTORY 
LOCATION OF THE uIRECTOiY 
ANJ the 5JHTASK NAME 


ENTRY FOR THE iUBTASK 
ENTRY FOR THE PROJECT RL-AN 
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lEMZL 3 

COMPONENTS OF ST^TE E.B 
RE-ACTIVATE OLD SUBTASK 


pArp TC 

POOD JSS 

QGaijp^ 


+ STATE OtSGRiPTIONS ‘>-***^ 


STATE luNS name AND TEXT 


F.3.A CHECK CUR^wNl STATUS 

THE 3JBTASK HAY OR MAY NOT HAVE AN .ACTIVE STEF AT 
THE TIME OF SIGN UN. IF NOT, THE NEXT STATE HILL ALWAYS 
BE COMMAND MOOE(F). IF A STEP 13 ACTIVE, THE CCNNECTIOri 
FROM THIS USER TO THE ACTIVE STEP MUST BE MADE. 


E.3.8 CONNECT TJ ACTIVc SThP 

establish the gcrrespcnoence oetheen the active 

i,T£P AND THIS ACTIVE USER SO THAT IT NIuL 6E OF ^40 
CONSEQUENCE THAT HE INTERRJPTEO. 


■>f**** ALLOWED TRANSITIONS *‘f-^** 


STATE 

TO STATE 

INPUT / 

OUTPUT / 

ENTRY) 

(i* = EXIT) 

'CONDITION 

RESULT 

A 

E.8.B 

1 

1 


r^F. A.A 

2 

2 

8 

r» * 

3 


,, ** 
!*\J 



*The state returned to is whatever state the currently 
executing STS represents. 

**Since V was interrupted, the precise state within V 
cannot be specified. 


A71 



/ N 
t FiA I 



I 



NOT 

KNOWN 


\ 


3/2 


E.8 t f?E-ACTI\/ATE OLD SUBTASK 
(CONTINUED) 


INPUT / CONDITION LIST 


NUM3ER TEXT 

1 SU3TASK DIRECTORY INDICATING THAT A STS IS 
CURRENTLY EXECUTING 

2 INACTIVE 3U3TASK DIRECTO^cY IN Cl, WHICH WAS 
NOT INTERRUPTED DURING STATE V 

.3 CONNECT SJCCESSrUL HESSASb FROM THE OS 
^ INACTIVE SUdTASK OIRtCTORY IN THE Gu WHICH 
WAS INTERRUPTED DURING STATE V 


^***‘(- OUTPUT / RESULT lIST 


MUiJER TEXT 

1 

2 LAST TERHI 'lAL OUTPUT MESSAGE 
i 


CROSS REFERENCEJ TRANSITIONS 


STATE IS ACCESSIBLE FROM 

E.a.A E.A.8 
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LEVEL 3 

C0HPG.VENT3 OF STATE E,C ' - . 

CREATE MEW SUiTASK ORtGINAi; PAOTM’ 

POOR QUAIiTS 


STATE DESCRIPTIONS 


STATE LONG NAME AND TEXT 


E.C.A SET UP SU3TASK OIHECTORV IN THE CL 

CREATE A LE IN THE CL OF TYPE OIRECTORY WITH -THE 
NA1E OF STN(PN) WHERE- STN = SUBTASK NAME AND PN = PROJLCT 
NAME, 


E.C.S SET UP SU ITASK RECORDS LE IN THE STL 

USING INFORMATION FROM THE PROJECT PLANS j THE 
ACCESS ANO PERMISSION CODE TA-3i.ES WILL 3E FORMULATED. 
THE ACTIVITY RECORD wiLL PE l?JITIATEO, ALONG WITH THE 
ACCOUNTING RECORD. 


E.C.C LIBRARY ENTRY INITIATION 

initialize ANY _E THAT ARE KNOWN TO BE ASSOCIATED 
WITH THE 3UBTASK PER THE PROJECT PLANS. THIS S'HOUlD 
ALWAYS INCLUDE A REPORT SKELETON. 



ALLOWED TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

(.♦ - ENTr.Y) 

(r* = EXIT) 

CONDITION 

RESULT 

1* L . G ■ A 

£. • C • S 

i 

j 

X 

E .C. B 

i~ ^ 

tl « Lf 4 o 

2 

2 


t*F .A .A 

3 

2 

E.C.C 

i*F . A , A 

4 

3 
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E.C I CREATE NEW SU3TASK 
(CONTINUED) 


INPUT / CONDI rllJ^4 LIST 


NUM3ER TEXT 

1 valid subtask name not CURRENTLir IN THE CL. 

POINTER TO ASSOCIATED PROJECT PLAN, 

^ SUBTASK RECORD FROM THE PROJECT PLAN CONTAININb AT 
LEAST 1 L£ TO 8E INITIALIZED 

3 SU3TASK RECORD FROM THE PROJECT PLAN WITH NO LE TO -iE 
INITIALIZED. 

4 l£ specifications for INITIAL SUBTASK LIORARY ENTRIES 


OUTPUT / RESULT LIST 


NUMBER TEXT 

i NEW DIRECTORY ENTRY IN THE CL FOR THIS SUBTASK 
^ 3UJTASK RECORDS LE ItaTIALIZEO IN THE STL 
3 lE SET UP IN STL 



GROSS REFERENCED TRANSITIONS ***** 


state’ IS ACCESSIBLE FRO^ 

E.C. A E.A.S 
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LEVEL 3 

COMPONENTS OF STATE F.A’ 

REQUEST USER INPUT ANO INTERPRET COMMAND 


STATE 
F.A. A 

F « A » B 
F . A . G 
F.A.D 


STATE OESGRIPTIONS 


LONG NAME ANO TEXT 


ASK FOR, REAS, ANO PARSE USERS CCMHANQ 

AFTER Prompting the user to insert an 
IPAD COMHANO, THE COMMANO IS-REAO ANO 
THEN THE CHARACTER STRIvJG FOR THE USER ClMMANO IS 
PARSED TO PRODUCE CONSTITUENT PARTS, THE MOST IMPOETANT 
BEING THE COMMAND VERB 


DETERMINl 30MMAN0 INTENT 

THE COMMAND INTENT MAT OR MAY NOT BE LEGITIMATE 
ANO IT MUST 8E CHECKED AGAINST THE CURRENT LIST. 


VERIFY PERMISSION TO USE CCMMANU 

USING THE SUBTASK RECORDS, CHECK TO_SEE THAT THIS 
USER.HAY EXECUTE THIS COMMAND. 


ACTIVATE IPAD UTILITY- 

INITIATE THE ACTIVITY REQUESTED FOR IN THE 
COMMAND. 
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F.A J i^tEQUEST USER li^JPUT AND INTERPRET COMMAND 
(CONTINUED) 


ALLOWED TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

((* = ENTRY) 

(»♦ = EXIT) 

CONDITION 

result 

[♦F • A • A 

F • A . 3 

i 

1 

F .A. B 

F.A. A 

E 

2 


F.A.G 

3 

3 


&F .G.A 

5 

5 


->T .A 

1:) 

c 


r»U.A 

2G 

9 

F • A « L/ 

F.A. A 

21 

1C 


■ F.A.D 

4 

u 

F , A.O 

G 

5 

6 


r»ti .B 

7 

6 


<♦1 

o 

6 


r*K . A ,A 

10 

o 


r* M . A . A 

12 

6 


i»N .A .A 

13 

b 


!*P .A 

14 

e 


r»Q.A 

15 

fc 


r» V . A 

IS 

7 


-♦K.A 

17 

t 
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LEVEL 3 TRANSITION DIAGRAM 
STATE F.A : INTERPRET COMMAND 
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F.A 1 REQUEST USER INPUT AND INTERPRET COMMANO 
(CONTINUEO ) 


****»■ input / CONDITION LIST ***** 


NUM3ER TEXT • 

1 CHARACTER STRING FORNATfED CORRECTLY FOR AN IPA-J 
COHMANU. 

2 UNRECOGNIZABLE COHMANU >JcRv 

3 VALID IPAD COWHAND VERB 

A PERMISSION CODE INDICATING USE IS VALID 

5 RETURN 

6 HELP 

7 SEARCH 

3 ENTER DATA 
n rtOJIFY DATA 

12 CONSTRUCT JJ3 

13 EXECUTE 
1--+ DISPLAY 
15 DISPOSE 
17 DEFINE 

TERMINATE 
13 STOP 
21 QUIT 

21 PERMISSION CODE INDICATING USE IS INVALID 


OUTPUT / result list 


NUMBER TEXT 

1 C.OMMANO VE'RO, ANY OTHER INFOKMATON SUPPLIED HITH 
THE VERB 

2 ERROR MESSAGE, ^^EQUEST FOR AWOT>lER TRY 

3 

*+ - 

5 PUSH DOWN STACK 

6 PARSED COMMAND , UPDATED ACTI VITY RECORD 

7 

.3 POINTER TO THE STS TO BE TERMINATED 
D *“ , • 

13 ERROR MESSAGE, REQUEST PDF' ANOTHER TRY 
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F.A t REQUEST USER INPUT AND INTERPRET CONMANO 
(CONTINUED) 


STATE 
F.A. A 


CRJS5 REFERENCED TRANSITIONS 


IS ACCESSIciLE FRO 1 

E.3.A 
E • u . D 
• E.C.C 
E .3. B 

H . sj • b 

H 9 ij . C 
h.J. 6 
H.D.C 
H 9 D . D 

H 9 J . £ 

M . C , 0 


ORIGINAE PSGSlSf 
OF POOR QUAiOT 
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STATE 

F • d . 

F »3 • 


L£\/EL 3 

COMPONENTS OF STATE F.B 
DE-AGTiVATE SUdTASK STEP 


STATE OESG‘^a?TlONS 


long name ANO TEXT 


PriEPA-<E S-JdTASK STEP FILES 

LOCATE All THE FIi_ES ASSOCIATEJ WITH THIS STS aMD 
PACKAGE THEM UF FOR REG DVERr" AT A LATt^ TIME. THIS Ml.L 
INTERFACE WITH THE OS. 


AOJUST STACK 

pur This sts in Tiie stack 


allowed, tpansitioms * + 


FROM STATE 

TO STATE 

I14PUT / 

OUTPUT / 

(r* = ENTP.ri 

(r» = EXIT) 

conoition 

RE SULT 

..I. A 

F.B.6 

1 

1 

F.S.d 

-♦F.A.A 

2 

2 


TRANSITION DIAGRAM 



7/2 


^ FiA.A 1 

%. * 
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F.8 i DE-ACTIVATE SU3TASK STEP 
(CONTIiMUEO) 


INPUT / CONDITION LIST 


NUM3ER TEXT 

1 PUSH DOWN STACK FOR INTERRUPTED STSj RECOVERif 
INFORMATION FROM THE STS ROLLOUT FILE 
> PUSH DOWf4 STACK UPDATE INFORMATION 


OUTPUT / RESULT LIST 


NUH3ER TEXT 

1 COMPlETELT DE-ACriVATLD STS 
PUSH DOWN STACK 

2 UPDATED PUSH DOWN STACK 


0 ? ^ 
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LEVEL 3 

COMPOI'IENTS OF STftTE F.C 
.^E-ACTIVAT£ SU3TASK STEP 


STATE OESCKIPTIONS 

STATE LOi^G NAME ANO TEXT 

F.C. A LOCATE STS 

^ USING THE PUSH DOWN STACK, IDENTIFY THE STS TO 8£ 

re-activated 


F.C.B PREPARE STS FOR RE-ACTIVATION 

THIS IS BASICALLY THE INVERSE OF F.B.A AS IT 
PREPARES A^L THE FILES OF THE STS FOR EXECUTION. 


F.G.C ACTIVATE STS 

RE-ISSUE THE LAST TERMINAL {MESSAGE AND REUUEST TMt 
OS TO ACTIVATE THE STS 



ALLOWED TRANSITIONS ***** 


FROH STATE 

TO STATE 

INPUT / 

OUTPUT 

(r* = ENTRY) 

(.* = EXIT) 

CCNDITICN 

RESULT 

f^F « C . A 

F.C.B 

1 

1 

F.C. 8 

F.C.C 

2 

2 

F.G.C * 


3 

3 



A 

3 


r»I 

5 

3 


f*K 

7 

3 



9 

3 


.♦N 

10 

3 


t»0 

11 

3 


i»P 

12 

3 


«*Q 

13 

3 


r»W 

15 

3 


*Since these are transitions to interrupted states, the 
node names at level 3 cannot be specified. 
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F.C * .^E-ACTrVAT£ SUBTASK STEP 
(CONTINUED) 


****»■ input / CONDITXGN LIST 


NUHBEk TEXT 

1 PUSH DOWN STACK AND THE LOCATION OF STS KOLlOUT FILE 
AND RECO\/ERY INFORMATON FOR THE STS AT THE TOP OF TH 
STACK 

2 PROPER RESTORE CODES ON ALL STS FILES 


i 

STS 

FILE 

GONTAININO 

AN 

INTERRUPTED 

STATE 

U 

A 

STS 

file 

CONTAINING 

AN 

IHTERRJHTEU 

STATE 

H 

3 

S TS 

FILE 

CONTAINING 

AN 

INTERRUPTED 

STATE 

I 

7 

STS 

FILE 

CONTAINING 

AN 

INTERRUPTED 

STATE- 

K 

9 

STS 

FIuE 

CONTAINING 

AN 

INTERRUPTEO 

STATE 

?-J 

13 

STS 

file 

CONTAINING 

AN 

INTERkUPTEO 

STATE 

N 

li 

S T3 

FILE 

CONTAINING 

AN 

INTERRUPTcO 

STATE 

0 

12 

STS 

FILE 

CONTAINING 

AN 

INTlKRUPTEO 

STATE 

P 

13 

STS 

FILE 

CONTAINING 

AM 

INTERRUPTED 

STATE 

a 


STS 

FILE 

CONTAInIING 

AN 

lNT:iRRUPTEO 

STATE 

w 


OUTPUT / RESULT l15T 


NUH3ER TEXT 

i STS FILE POINTER(S) 

3 all STS files ready TO EXECUTE 

S last RECOROEO line SENT TO THE TERMINAL 
MOOIFIEO »JSH OOrtN STACK 


****■<(■ CROSS REFERENCED TRANSITIONS 
STATE IS accessible FRO 1 


F.C. A 


F • A « U 
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LEVEL 3 

COMPONENTS OF STi\TE H.C 
USE.^ CONTROLLED SEARCH 


STATE DESCRIPTIONS 


STATE LONG iUME AND TnXT 


H.C. A DETERMINE SEARCH MODE 

THE JSER HAS ALREADY INDICATED THAT HE WANTS TO 
CONTROL THE LIBRARY SLARCri. HE ENTERS INTO AOOITIOMAl 
DIALOG, IF NECESSARY, TO SPECIFY wHAT HE IS LOOKING FOR 
AND HOW HE WANTS TO INTERACT WITH THE SYSTEM 


H.G.b PERFORM SINGLE ITEM SEAkGH 

THE USER HAS RcQUEST-rj AN EXISTENCE SEARCH FOR A 
single item. IF FOUND HE MAY CHOOSE TO OISPLAY THE ITEh 


H.C.C PERFORM PAGED SEARCH 

THE JSER WANTS TO PAGE THROUGH A DIRECTORY OR A 
DICTIONARY. WHEN EXAMINING DIRECTORY ENTRIES THE USER 
MAY REaUbST DISPLAYS OF INDIVIDUAL L 1 8RARY-ENTF-.IES . 


***** allowed TRANSITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(c = ENTRY) 

= EXIT) 

CONDITION 

PxESULT 

r*-H .C.A 

H.C. A 

1 

1 


H »C . 3 

S 

2 


H .C.C 

7 

2 


f*H .D.A 

d 

6 

H .C.B 

-»F .A .A 

5 

6 


H .C.A 

b 

1 


H.C.J 

3 

o 


-♦H.E 

A 

4 

H.C.C 

-f.a.a 

5 

b 


H.C, A 

b 

1 


H.C.C 

3 

3 


i*H »£ 

4 

b 
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LEVEL 3 TRANSITION DIAGRAM 
STATE HX : USER CONTROLLED SEARCH 
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H.C * USER CONTROLLEO SEARCH 
(CONTINUED) ... 


INPUT / CONDITION LIST 


NUM3ER TEXT 

1 USER/STSTEM DIALOGUE INCOMPLETE 

2 USER WANTS EXISTENCE S£i\RCH 
i SEi\RCH COMPLETED 

displav desired 

5 USER FINISHED NITh SEARCH ACTIVITY 

8 USER l^ANTS TO INITIATE A NEW -SEARCH ( WITHOUT DISPLAY, IF 
ITEM FOUND) 

7 USER WANTS PAGED SEARCH 

S USER WANTS TO SWITCH TO SYSTEM CONTROLLED- SEARCH 


OUTPUT / RESULT LIST 


NUH3ER , TEXT 

1 SirSTEH MESSAGE REUUESTiNG MORE DATA 

2 SEARCH/SELEuTlON CRITERIA 

3 USER COMMAND TO DISPLAY OR NOT, TO END, OR TO B'El,1N NEw 
SEARCH 

^ LOCATION OF ITEM TO BE DXSPLAfEO 

5 LOCATION OF DICTIONARY OR DIRECTORY 

6 “ 


ORIGINAL PAGE IS 
OF POOR QUAiOT 
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STATE 
H. J.A 

H.D.B 
h. J.G 
H.J.D 

H.O.E 


LEVEL 3 

COHPONENTS OF STATE H.D 
SYSTEM CONTROLLED SEARCH 


ORIGINAL PAGE I& 
Og ROOR QUAUX^ 


STATE DESCRIPTIONS ***^* 


LONG NAME AND TEXT 


EVALUATE SELECTION EXPRESSION 

THE USER PROVIJES A SET OF INFORMATION USED BY THE 
SYSTEM TO SELECT AND EXTRACT DATA FOR DISPLAY. THE EX- 
PRESSION EVALUATION ALSO DETERMINES THE TYPE OF SuARCri 
NHICH WILL DE UNDERTAKEN. 


KEYWORD SEARCH 

KEYWORDS IN OIGTlONARr ENTRIES (ElThEF Cl J!< STL) 
ARE USED TO LOCATE LIBRARY ENTRIES. 


REFERENCE SEARCH 

EXPLICIT REFERENCES SUCH AS ♦USED 3Y» ARE USED ID 
LOCATE library ENTRIES. 


ATTRIBUTE SEARCH 

SIMILAR TO KEYWORD SEARCH. ATTRIBUTE INDEXES CAN 
3E ESTABLISHED 3Y THE USER EXPLICITLY BY UTILIZING LE 
TYPE Olf^CTORY. THE DATA BASE MANAGEMENT SYSTEM WILL 
INCLUDE FACILITIES FOR ESTA BLISHMENT AND MAINTENANCE 
OF ATTRIBUTE INDEXES BY SUPPORTING FILE INVERSION. 


value (CONTENT) SEARCH 

OATA AGGREGATES ARE SELECTED BASED ON VALUES OF 
VARIABLES. THIS FOR’t OF SEARCH MAY RANGE OVER MORE HAN 
ONE OATA SET. 
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H.O t SrSTEM CONTROLLcO SEARCH 0* ^ 

(CONTINUED ) 


***** allowed transitions ***** 


FROM STATE 

TO STATE 

INPUT /' 

OUTPUT / 

(.» = ENTRY) 

= EXIT) 

CONDITION 

result 

i*H .0 . A 

(*h .C 

la 

c 


H.O. A 

I 

1 

• 

H .D .H 

2 

2 


H • I) * ^ 

7 

2 


ri . D.u 

3 

2 


H .D.E 

9 

2 

H • 0 • 6 

/+ F ♦ A • A 

5 

5 


H .O.A 

6 

1 


H .0.3 

3 

5 


.•♦H .E 

A 

4 

H ,Q.G 

i+F . A . A 

5 

5 


ti .D.A 

6 

1 


H.D.C 

5 

3 


r»H . E 

A 

4 

H • □ • 0 

.A.A 

5 

5 


H . D . A 

6 

1 


H.D.J 

6 

2 


-»H.E 

4 

4 

ri • J » E 

r* F . A . 4 

5 

a 

_✓ 


H.O. A 

6 

1 


H . 0 . (L 

3 

3 


.♦H.E 

4 

4 
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4/4 



H.O t SYSTEM CONTROLLED SEARCH 
(CONTINUED) 


INPUT / CONDITION LIST >f-**** 


NUHSER TEXT 

1 USER/SYSTEH OIAlOO INCOMPLETE 
. 2 KEYWORD SEARCH REQUIRED 

3 SEARCH COMPLETED 

4 DISPLAY DESIRED 

3 USER FINISHED WITH SEARCH ACTIVITY 

6 USER WANTS TO INITIATE NEW SEARCH 

7 USER WANTS REFERENCE SEARCH 

3 USER WANTS ATTRIBUTE SEARCH 

) USER WANTS VALUE (CONTENT) SEARCH 

. 13 USSR wants to switch TO USER CONTROLLED SEARCH 


OUTPUT / RESULT t.I3T 


NUMBER TEXT 

1 SYSTEM MESSAGE REQUEbTiMu MORE DATA 

P SEARCH/SEuECTION CRITERIA 

3 USER COMMAND TO DISPLAY OP NOT, TO END, CR TO bSGlN NEW 
SEARCH 

A LOCATION OF DATA TO d£ DISPLAYED 

5 - 


CROSS REFERENCED TRANSITIONS 


STATE 


IS ACCESSIBLE FROM 


H • D * A 


H.C. A 
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LEVEL 3 

COMPONENTS OF STftTE I.C 
CONSTRUCT LIBRARY ENTRY 




STATE DESCRIPTIONS ***»■* 


STATE 


I.C. A 


1 .C.B 


I.G.C 


I.C. D 


I.O.E 
l.C.F 
I . C . G 
I.G.H 


LONG NAME AND TEXT 
SELECT APPROPRIATE PROCESSING MODE 
ENTER COOING MOUULE 
ENTER DATA SET 

ENTER STORED DATA DEFINITION 
ENTER DICTIONARY 
ENTER DISPLAY FORMAT 
ENTER display MENU 
ENTER PLAN 


I.C. I ENTER REPORT 


I.C.J ENTER DATA CONTROL DATA 

THIS IS THE STATE OF ENTERING THE INITIAL DATA TO 
CONTROL ACCESS TO DATA AND SYSTEM FUNCTIONS. ALL SUD- 
SEOUENT- CHANGES TC THIS CONTROL liJFORMATION IS DONE VIA 
THE MODIFY STATE. 


I.C.K ESTABLISH DIRECTORY ENTRY 

A DIRECTORY ENTRY IS ESTABLISHED IN THE USERS WORK 

AREA 
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I.C * CONSTRUCT LIBRARY ENTRY 
(CONriNilEQ), 

***’!•* STATE DESCRIPTIONS (GONTINUEO) 

STATE ' LONG NANE ANJ TEXT 

I.C.L COMPLETE JIRECTORY ENTRY 

AUDITIONAl information is added to the LSTA3LISHED 
DIRECTORY ENTRY 

I.C.H REPORT ERROR 
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I.C t CONSTRUCT LIBRARY ENTRY 
tCONTlNUED) 




allowed transitions 


FROM STATE 

T.O STATE 

INPUT / 

OUTPUT 

(.♦ = ENTRY) 

(<* = EXIT) 

CONDITION 

RESULT 

r»I .C.A 

I .U.B 

1 

1 


I.C.C ' 

2 

1 


I.C.D 

3 



i.C.E 

4 

J. 


I .C .F 

5 

1 


I .C.& 

6 

1 


I .C .H 

7 

1 


I . C . I 

6 

1 


i. . C . 0 

3 

1 

X • * B 

I.C.K 

10 

1 


I.C.u 

22 

1 


1 . C . M 

13 

1 

I .o.c 

I .C.K 

13 

1 


I.C.L 

22 

1 


I .C.N 

14 

A 

X 

X • • U 

I . L . K 

iu 

1 


I.C.L 

22 

1 


I.C.i'l 

15 

1 

I.C.c 

I.C.K 

10 

1 


I.C.L 

22 

1 


I.C.M 

lb 

1 

I.C.F 

I.C.K 

10 

1 


I.C.L 

22 

1 


I.C.M 

17 

A 

X 

I .G.& 

I.C.K 

10 

1 


I.C.L 

22 

1 


I.C.M 

13 

1 

I .C.ri 

I.C.K 

IQ 

1 


I.C.L 

22 

1 


I.C.M 

13 

1 

I .C.I 

I.C.K 

10 

1 


I.C.L 

22 

1 


I.C.M 

23 

1 

X • C • <J 

X . G . -K 

13 

1 


I.C.L 

22 

1 


I . C . H 

21 

1 

I.C.K 

I.C. 3 

12 

1 


I.C.C 

12 

■1 


I.C.O 

12 

1 


I.C.E 

12 

K 
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ORIGINAL PAGE & 
DE POOR QUALITY, 


I.C : CONSTRUCT LIBRARY ENTRY 
(CONTINUED) . 


***** ALLOWED 

TRANSITIONS 

(CONTINUED) 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

= ENTRY) 

(t» = EXIT) 

CONDITION 

RESULT 

X • K 

I ,c.f' 

12 

1 


X • C « I 3 

12 

1 


I .C.H 

12 

1 


I.C. I 

12 

1 


I .C.J 

12 

1 


l.C.K 

11 

2 

I .C • L 

r»I.D 

23 

1 

I .G.M 

I.C. 3 

24 

1 


I . C . G 

24 

1 


I.C.Li-, 

24 

1 


I.C.E 


1 


I.C.F 

24 

1 


I . c . c 

24 

1 


• I. C.H 

24 

1 


I .C.I 

24 

- 1 


I .C.J 

24 • - 

i 
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I.C t CONSTRUCT LIBRARY ENTRY 
(CONTINUED) 


INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 ENTER CH 

2 ENTER OS 

3 ENTER SOD 

4 ENTER QIC 

5 ENTER DF 

6 ENTER ON 

7 ENTER PLAN 

6 ENTER REPORT 

9 ENTER DCO 

10 READY TO 3EGIN LibRARY ENTRY CONSTRUCTION 

11 USER SUPPLIED DIRECTORY INFORMATION INCOMPLETE 

12 DIRECTORY cNTRY ESTAOLISNEO IN USER WORKING SPACE. 

13 ERROR MESSAGE (CONSTRUCT CM ERROR) 

U ERROR MESSAGE (CONSTRUCT OS ERROR) 

15 ERROR MESSAGE (CONSTRUCT SCO ERROR) 

16 ERROR MESSAGE (CONSTRUCT QIC ERROR) 

17 ERROR MESSAGE (CONSTRUCT OF ERROR) 

Id ERROR MESSAGE ■ (CONSTRUCT OH ERROR) 

19 ERROR MESSAGE (CONSTRUCT PLAN ERROR) 

29 ERROR MESSAGE (CONSTRUCT REP ERROR) . 

21 ERROR MESSAGE (CONSTRUCT DCO ERROR) 

22 library entry CONSTRUCTION COMPLETE, LE IN USER WORKING 
AREA 

23 DIRECTORY ENTRY FOR NEW Lt COMPLETED 

24 ERROR CONDITION CLEARED, SOME RECOVERY POSSIBLE 


***** OUTPUT / RESJLT LIST ***** 


NUMBER TEXT 

1 

2 MESSAGE REQUESTING MORE INFORMATION 
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level 3 

COMPONENTS OF STATE K.A 
CONNECT USER WITH DATA TO BE MODIFIED 


STATE 
K.A. A 


K.A.B 

K.A.C 

K.A.O 

K.A.E 

K.A.F 


***‘>“f- STATE DESCRIPTIONS 


LONG NAME AND TEXT 


INTERPRET COMMA NO 

THE MJOIFY ACTIVITY POTENTIALLY INVOLVES UPDATING 
ANY LiBriARY ENTRY IN THE DATA BASE. THIS MAY 3E ENGIN- 
EERING DATA IN A DATA SET OR SOURCE CODE IN A CM. 

MODIFICATION MAY INVOLVE THE CREATION OF A NEW 
VERSION CF AN L£ IN WHICH CASE THE PREVIOUS VERSION IS 
AVAILABLE JNCHANGEu IN THii DATA BASE. IF MOOIFICAirON 
INVOLVES CORRECTION CF A PREVIOUS VERSION THE RETENTION 
OF THE PREVIOUS VERSION IS OPTIONAL. 


RcTRiCVe OIRhCTORY ENTRY 

DIRECTORY ENTRY FOR THE lE TO BE MOOIFItO IS USED 
FOR validation AND ID ATTACH TEXT TO USER 


VALIDATE USER 

AS FOR ENTER A USER MUST HAVE PERMISSION TO CARRY 
OUT MODIFICATIONS. PERMISSION IS GRANTED 3Y PROJECT 
MANAGEMENT AND AOMINISTERLO BY IPAD. PERMISSION MAY OE 
SPECIFIC WITH RESPECT TO LE TYPES, CL OR STL, SECURITY 
CLASSIFICATION, AND PARTICULAR OCCURRENCES 


CHECK PREVIOUS USAGE 

INADVERTENT PURbiNG OF DATA 8Y REWRITING DATA THAT' 
MIGHT still be RtUUIREO HOST BE AVOIDED. PREVIOUS USERS 
WILL 3E INFORMED THAT MODIFICATIONS HAVE BEEN MADE AND 
THE UNMODIFIED DATA kET AIMED. 


ATTACH EXISTING LE TO USER 


ATTACH COPY OF EXISTING LE TO USER 
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K.A a CONNECT USER WITH DATA TO 8E MODIFIED 
(CONTINUED) 


STATE 

K.A. 


STATE DESCRIPTIONS (CONTINUED) 


LONG NAME AND TEXT 


SELECT MODIFY PROCESSOR 

INFORMATION COLLECTED FROM THE COMMAND 13 USED TO 
DETERMINE WHICH HOOIFT PROCESSOR IS TO HE USED 


♦ ALLOWED TRAr4SITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

Ci* = ENTRY) 

(i* = C.XIT) 

CONDITION 

RESULT 

f*K.A. A 

K .A .A 

1 

1 


K . A . a 

2 

2 


K.A.C 

5 

5 


K . A • 0 

9 

9 


K.A.F 

12 


K.A.B 

K.A. A 

4 

4 

K.A.C 

K.A. A 

6 

1C 

K.A.O 

K . A .E 

10 

1C 


K.A.F • 

11 

b 

K . A . E 

K » A • G 

13 

1C 

K . A . F 

K . A . j 

13 

u 

K . A . G 

(►K . b . A 

14 

IL 


I* K . B . 8 

15 

1C 


!* K » 8 *u 

16 

ID 


-K.a.o 

17 

1C 


i* K » B .E 

Id 

iC 


>*K . B.F 

18 

1C- 


<*K.B.G 

2Q 

1C 


■ r»K.b.H 

21 

lu 


f* K « 8 1 1 

22 

1C 


j»K .8 *J 

23 

1C 


f»K , B.K 

24 

le 
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LEVEL 3 TRANSITION DIAGRAM 

STATE K.A: CONNECT USER WITH DATA TO BE MODIFIED 
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K.A I CONNECT USER WITH DATA TO 3c MODIFIED 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 MORE -INFORMATION RE )UI i£D TO COMPLETE COMMAND ANALSI3 

2 LIBRARY AND LIBRARY ENTRY TO 3L tlOUIFIED IDENTIFIED 

A DIRECTORY ENTRY FOR LE OBTAINED ■ 

5 i/ALlDATION REOUIREO 

6 VALIDATION CHECK OK 

3 VALID USER, COMMAND ANALYSIS COMPLETE , REWR ITE REQUESTED 

10 NO PREVIOUS USAGE OF LE TO BE MODIFIED 

11 PREVIOUS Lc USAGE DETERMINED 

12 VAlIO USER, command AnAYSIS COMPLETE, UScR WANTS TO PR 
SERVE PkEVIOUS VERSION AND CREATE NEW VERSION CONSID 
ED A VARIANT RATHER THA 4 A CORRECTION. 


, ii LE ENTRY ATTACHED TO USE^ 


14 

USER 

DESIRES 

TO 

MODIFY 

A 

CODING MOOUl 

c. 

15 

U SER 

DESIRES 

TO 

M DO IF Y 

A 

OPERATIONAL 

module 

16 

USER 

DESIRES 

TO 

MODIFY 

A 

JOB 


17 

USER 

DESIRES 

TC 

HOD IF Y 

A 

DATA SET 


13 

USER 

DESIRES 

TO 

MODIFY 

A 

DISPLAY FORMAT 

13 

USER 

DESIRES 

TO 

MODIFY 

A 

OICTIGNmRY 


2) 

USER 

DESIRES 

TO 

MODIFY 

A 

DISPLAY MENU 


21 

USER 

DESIRES 

TO 

MODIFY 

A 

PLAN 


22 

USER 

DESIRES 

TO 

MODIFY 

n 

REPORT 


23 

USER 

DESIRES 

TO 

MODIFY 

A 

STORED DATA 

DEFINITION 

2*+ 

USER 

DESI.RCS 

TO 

MODIFY 

DATA CONTROL DATA 


***** OUTPUT / RESULT LIST ***** 


NUMBER text 

1 MESSAGE .REQUESTING USER TO ENTER MODRE DATA 

2 LIBRARY ID AND LE NAME, TYPE 

4 DIRECTORY ENTRY IN USERS WORKING AREA 

5 SPECIFIC ITEM/ ACTION RElUlRING APPROVAL 
B LIST OF PREVIOUS USERS 

3 PARSED COMMAND AND COMMAND CONTROL TABLE 
ID 

***** CROSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 

Kt A • ^ FtA#U 
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LEVEL 3 

C.OMPOf>l£NTS CF 3T4TE K,8 
PERFOi^M MOOIFICATIOMS WITH DIALOG 


STATE DESCRIPTIONS 

STATE LONG NAMc AND TEXT 


K.D. A 

MOOIFlt' 

CH 

K.T.6 

HO DIPT 

OM 

K.3.C 

MODIFY 

J03 

K . 3 . 0 

HOUIFY 

DS 

K.3.E 

MODIFY 

D'F 

K.3.F 

MODIFY 

DIO 

K * 3 • G 

MODIFY 

DM 

K . i . H 

MODIFY 

PLAN 

K.5.I 

MODIFY 

REPORT 

K • 3 • J 

MODIFY 

S3 J 

K.3.K 

MODIFY 

DGO 


ORIGINAL PAGE Ib 
OE POOR QUALITY 
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K.e * PERFORM MODIFICATIONS WITH DIALOG 
(CONTINUED) 



****=f- ALLOWED TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(f» = ENTRY) 

(<♦ = EXIT) 

CONDITION 

RESULT 


K.3.A 

I 

1 


(* K • G . A 

2 

2 

i*K.R.B 

K.3.3 

1 

1 


K ♦ G * A 

2 

2 

I* K • '3 • C 

K.a.c 

1 

1 


K » b • A 

2 

2 

(♦K .B* 0 

K.0.0 

i 

1 


i*K • C . A 

2 

2 

K • B « E 

K.8.E 

1 

1 


.♦K.C.A 

2 

2 

i^K.D.F 

K • 8 » F 

1 

1 


r»K . C . A 

2 

2 

I* K • 3 • b 

i^.e.G 

1 

1 


K • b • A 

2 

2 

[♦K • 3 • H 

K.B.ri 

1 

1 


K • C • A 

2 

2 

i*K .'3 . 1 

K.8.I 

1 

1 


r* K • C • A 

2 

2 

(♦K.3. J 

K.3. J 

■ 1 

1 


t* K • L • A 

2 

2 

t»K.3.K 

K.B.K 

1 

1 


r* K » C » A 

2 

2 


TRANSITION DIAGRAM 



A105 




K,8 t PERFORM MODIFICATIONS WITH DIALOG ■ 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 flODIFtCATIDNS INCOMPLETE 

2 MODIFICATIONS COMPLETE 


***** OUTPUT / RESULT lIST ***** 


NUM3ER TEXT 

1 MESSAGE REQUESTING MORE DATA 

2 LE TEXT COMPLETE IN USER WORKING AREA 


***** CROSS REFERENCED TRANSITIONS ***** 


STATE 

IS ACCESSIdLE F'ROM 

K.B.A 

K • A • G 

K.6,8 

K*A.G 

K.8.C 

K.A. G 

K.d.O 

K * A • G 

K.S.E 

K ♦ A • G 

K.B.F 

K.A.G 

■K.B.G 

K,A.G 

K.B.H 

K.A.G 

K.B.I 

K.A.G 

K.B.U 

K.A.G 

K.8.K 

K.A.G 
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LEVEL 3 

COMPONENTS OF STATE K.C 
UPDATE DIRECTORY ENTRY 


STATE DESCRIPTIONS **‘>-^* 


STATE 


LONG NAME AND TEXT 


K.G.A UPDATE TEXT LOCATION SPECIFICATiONSClLS) 

ALL 3UFFER3 ARE FLUSHED MOVING ANY REMAINING DATA 
OUT TO THE DATA BASE, RECCRUING ADDITIONAL LOCATING IN* 
FORMATION IN DIRECTORY. 


K.O.e UPDATE USAGE INFORMATION 

DATE OF LAST ACCESS, UID OF. ACCESSER, ACCESS COUNT 
ARE ENTERED IN DIRECTORY. 


K.C.C UPDATE DATA SET REFERENCE TABLE 

THt SUBTASK LE DATA SET REFERENCE TABLE IS UP- 
DATED FOR THE DATA SET WHICH WAS MODIFIED, 


K.G.D UPDATE STATUS INFORMATION 

THE USER MAY CHANGE THE STATUS OF THE LE (IF HE IS 
VAi-IOATED TO CO SO). THIS MA^ INVOLVE LEVEL OF CERTI- 
FICATION, ANALYSIS LEVEL, INTERNAL STRUCTURE, ETC. 



ALLOWED TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

(r» = ENTRY) 

(r» = EXIT) 

CONDITION 

RESULT 

K . C . A 

K . C • D 

1 

i 

K .0.3 

K.C.C 

2 

1 


K.C.D 

3 

1 

K.C.C 

K.C.O 

4 

1 

K.C.O 

K.C.D 

5 

2 


^K.O 

6 

1 
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K.C t UPDATE DIRECTORy ENTRY 
(CONTI'NUED) . ■■ ■' 


♦ INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 BUFFERS FLUSHED, ENTIRE lTE ON DATA BASE STORAGE DEVICE 

^ USAGE INFORMATION UPDATE COMPLETE. LE IS TYPE 03 AND IS 

IN THE CL. 

3 USAGE INFORMATION UPDATE COMPLETE. LE IS NOT TYPE DS. 

4 DATA SET REFERENCE TAbLE IN THE ST LE UPDATE COMPLETE 

5 STATUS INFORMATION UPDATE .MOT COMPLETE 

o STATUS INFORMATION COMPLETE 


***** OUTPUT / RESJLT LIST ***** 


NUMBER TEXT 

1 

2 MESSAGE TO USER TO EnTER MORE INFORMATION 


***** GROSS REFERENCED TRANSITIONS ***** 


STATE 
K.C. A 


IS ACCESSIBLE FROM 

K . 3 . A 
K . 3 . A . d 
K . B . A . G 
K.3.B 
• K.3.B.3 
K . d • B . C 
K . 3 . C 
K.d.C. 3 
K * 3 « C . C 
K.3. 0 
K.d.O, 3 
K. 3.D.C 
K.3.E 
K.d.F 
K.3.G 
K.d.H 
K.3. 1 
K . -3 . J 
K . .3 , K 
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LEVEL 3 . original Page 

COMPONENTS OF STATE M.A OP POOl? nriA 
DETERMINE AVAILABLE JOB COMPONENTS WAXJTSj ‘ 


STATE DESGRIFTIONS 


STATE 


LONG NAME AND TEXT 


M . A . A 


establish the list of OMS for this JC'i 


ASK FOR AND INTERPRET THE LIST OF OMS GIVEN 8Y 
T he U5£k« 


M.'A. 3 


SEARCH FOR OM NAMES IN THE STL 


TRY TO 
LIST OF OMS 


SATISFY THE wIST OF REQUIREO OMS WITH THE 
RESIDING IN THE STL. 


M, A.C 


SEARCH FOR GM NAMES IN THE CL 


TRY TO 
LIST OF OMS 


SATISFY THE LIST OF REQUIRED' OMS ^ITH THE 
RESIDING IN Tri£ CL 


M.A.O CHECK ACCESS TO CL RESIDENT CMS 

ANY OHS REQUIRED WHICH RESIDE IN THE CL MUST EE 
AC2ES3ABLE TO THIS USER IN EXECUTE MODE. 


ALLOWED TRANSITIONS ****»■ 


FROM STATE 

TO STATE 

INPUT ( 

OUTPUT 

(<* = ENTRY) 

(»♦ = EXIT) 

CONDITION 

RESULT 

(♦M • A • A 

M.A. 3 

1 

1 

H . A . 8 

M.A.C 

3 

5 


'♦M .C .A 

2 

2 

M.A.C 

M.A.J 

5 

5 



4 

4 

M.A.O 

c* M • B « A 

6 

6 


f».M . 3 • A 

7 

7 


f* M . C . A 

0 

a 


Alio 



2 / 2 . 



1/1 


M.A< 



LEVEL 3 TRANSITION DIAGRAM 
STATE Mi A : DETERMINE AVAILABLE JOB COMPONENTS 


Alll 



M.A i OETERHINE AVAILABLE JOB COMPONENTS 
(CONTINUED) 


INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 LIST OF REOUIREJ OMS 

2 STL OM DIRECTORY CONTAININC THE NAMES OF ALl REaUIREO 
OMS 

3 STL OM DIRECTORY CONTAININC LESS THAN AlL THE NAMES OF 
REQUIRED OHS 

=+ CL OM DIRECTORY CONTAINING NONE OF THE NAMES IN THE 
GIVEN SEARCH LIST 

5 CL OM DIRECTORY GCNTAINING AT LEAST i OM NAME IN THE 
GIVEN SEARCH LIST 

6 ACCESS C30E TABLE DENYING EXECUTE PERMISSION FUR AT 
LEAST 1 Cl resident OM 

7 ACCESS CODE TABLE GIVING EXECUTE PERMISSION FOR ALL 

CL RESIDENT OMS FOUND, AND A CL OH DIRECTORY CONTAINING 
LESS THAN AlL THE REQUIRED CMS. 

3 ACCESS CODE TABlE GIVING EXECUTE PERMISSION FUR Al L 
CL RESIDENT OMS FOUND, AND THE COMBINED STL, CL OM 
DIRECTORIES CONTAIN ALL REQUIRED OMS. 


OUTPUT / RESULT LIST ***** 


NUMBER TEXT 

1 USERS OM LIST 

2 LIST OF NAMES FOUND IN THE STL 

3 LIST OF NAMES FOUND IN THE STL AND THOSE NOT FOUND 

A LIST OF NAMES FOUND IN THE STl AND THOSE NOT FCUNU 

IN THE CL 

5 LIST OF OMS FOUND IN THE Cl AND THOSE NOT FOUND 

6 LIST OF STL OMS FOUND, CL CMS FOUND AND ACCESSA8LE, AND 
CL OMS FOUND BUT NOT ACGESSABLE 

7 LIST OF FOUND AND ACGESSABLE OHS ^tNQ THOSE NOT FOUND 
3 LIST OF ALi. required OMS 

***** CROSS REFERENCED TRANSITIONS ***** 


IS ACCESSIBLE FROM 

F.A.O 
M.3.F 
M • C • 0 
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STATE 
M.A, A 



LEVEL 3 

COMPONENTS OF STATE M.B 
CONSTRUCT AN QM LIBRARY ENTRf 


STATE 

M.O.A 

M.a.6 

M.3.C 

II . i . D 

M.3.E 


STATE DESCRIPTIONS ***** 


LONG NAME ANO TEXT 


FORM Initial directory entry 

SET J? THE DIRECTORY ENTRY PROTOTYPE AND FILL IN 
CURRENTLY AVAILABLE ITERS ;.IKE NAME ANO TYPE. 


PROCESS FUNCTIONAL DESCRIPTION 

REQUEST A FUNCTIONAL DESCRIPTION FROM THE USER, 
VALIDATE The FORM, AUD INSERT IT IN THE DIRECTORY ENTRY 


PROCESS THE TEXT CONTROL DATA 

REQUEST THE ELEMENTS OF THE TEXT CONTROL DATA, 
VAlIUATE FROM CURRENT CM L£, AND CONSTRUCT THE TCD 


CREATE THE TbXT ENTRY 

GATHER ALL THE COMPONENT CMS, EXTRACT THE BINARY 
DECKS, DO ANY NECESSARY PRE-LOADING, AND CONSTRUCT 
THE EXECUTABLE LOAD FILES, 


CREATE CONTROL CM 

IF THE CMS MAKING UP THE OM DO NOT CONTAIN A MAIN 
PROGRAM, A control PROGRAM MUST 8E SUPPLIED BY THE USER 
AT THIS TIME, 


ENTER OM INTO THE STL 

MAKE THE FORMAL ENTRY OF THE OM INTO THE SUBTASK 

library. 
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M.e I CONSTRUCT AN OH LIBRARY ENTRY 
(CONTINUED) 



allowed TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(.♦ = ENTRr) 

(r» = EXIT) 

CONDITION 

RESULT 

f*M .B. A 

M.8.3 

1 

1 

M.B.8 

M.8.C 

2 

2 

M .3,C 

M.B.D 

S 

3 


M »B . E 

4 

3 

M.3.0 

M.B.F 

5 

4 

M . 3 . E 

M.8.0 

6 

5 

M.3.F 


o 

b 


t* M ♦ C . A 

7 

6 


I* M . C . C 

9 

e 
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/ \ 
y M.A.A ) 


LEVEL 3 TRANSITION DIAGRAM 
STATE M,B ; CONSTRUCT AN OM LIBRARY ENTRY 


Alls 


M.8 t CONSTRUCT AN OH LIBRARY ENTRY 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 NAME OF THE OM 

2 VALID FUNCTIONAL DESCRIPTION 

3 VALID USER SUPPLIED PURTION OF THE TEXT CONTROL DATA 
A LIST OF COMPONENT CHS LACKING A MAIN PROGRAM 

5 DIRECTORY AND DICTIONARY INFORMATION CONSISTENT HI TH 
THE USERS PORTION OF THE TEXT CONTROL DATA 

6 VALID CM control PROGRAM 

7 OM DIRECTORY INDICATING ThAT ALL REQUIRED CMS ARE 
DEFINED AND AOCESSA3LE 

0 NON-EMPTY LIST OF OHS TO ?h C'EFINEO 

9 NON-EMPTY lIST OF OHS TO BE DEFINED AND AN ENTRY FLAG 

FROM M.C.G. 


OUTPUT / RESULT LIST ***** 


NUMBER TEXT 

1 PARTIALLY COMPLETED DIRECTORY ENTRY 

2 FUNCTIONAL DESCRIPTION PlACEO IN THE DIRECTORY ENTRY 

3 USERS PORTION OF THE TCD IN THE DIRECTORY ENTRY 

4 COMPLETE DIRECTORY AND TEXT ENTRY FOR THE CM 

5 NEW. CM DEFINED IN THE SJ8TASK LIBRARY, AND OUTPUT S 

o NEW OM DEFINED IN THE SU3TASK LIBRARY 


***** CROSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FRO 1 


M.8. A 


M, A.C 
M. A.u 
M.A, D 
H.C.C 
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LEVEL 3 

COMPONENTS OF STATE M.C 
CONSTRUCT A JOB uIBRARY ENTRY 


POOR QUALITYf 


***** STATE OESCRIPTIONS ***** 


STATE 


LONG NAME AND TEXT 


M.C. A CONSTRUCT THE OM NETWORK 

REQUEST THE NETWORK DESCRIPTION FROM THE USER AND 
CONSTRUCT AN ANALYTICAL EXPRESSION OF THE NETWORK 


M.G.B VALIDATE THE INTERNAL/EXTERNAl UATA FLOW 

TAKING THE OM SPECIFIC ATIONS , CONSTRUCT THE ACTUAL 
DATA FLOW WHICH WOULD OCCUR DURING EXECUTION AND ASK 
FOR USER VALIDATION. NOTE THAT EXECUTION TIME DECISIONS 
MAKE IT IMPOSSIJLE TO ANTICIPATE ALL POSSIBILITIES 


M.C.C MODIFY THE OH NETWORK 

IF THE DATA FLOW 13 NOT AS DESIRED, NETWORK 
MODIFICATIONS MAY BE NECESSARY. 


M.C.D DEFINE THE JOB IN THE SUBTASK LIBRARY 

TAKING THE NETWORK uESCRIPTION AND THE COMPONENT 
QMS, CONSTRUCT THE JOB DIRECTORY ENTRY AND THE SYSTC1 
CONTROL CARD SKELETON RECuRO. 



J(. if. 

ALLOWED TRANSITIONS ***** 


FROM 

STATE 

TO STATE 

INPUT / 

OUTPUT / 

(f* = 

ENTRY) 

= EXIT) 

CONDITION 

result 

.*M ,C, 

.A 

M.C.B 

1 

1 

M .C . 

.8 

H.C.C 

2 

1 



M.C.U 

5 

3 

I* M » G 1 

>C 

(♦M.8.A 

A 

2 



M.C.b 

. 3 

1 

M.C. 

.0 

<*F .A. A 

6 

k 



r»M. A,A 

7 

u 


All? 




H.C * CONSTRUCT A JOB LIBRARY ENTRr 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 VALID NETWORK SPECIFICATIONS 

2 USERS RESPONSE THAT THE DATA FLOW IS NOT AS DESIRED 

3 valid network modification SPECIFICATIONS 

A USERS RESPONSE THAT ONE OR MORE GMS ARE MISSING 

5 DICTIONARY ANO DIRECTORY INFORMATION COMPATIBLE WITH 
THE NETWORK SPECIFICATIONS. 

6 EMPTY LIST OF JOSS TO BE OtFINEO 

7 NON-EMPTY LIST OF JOBS TO BE DEFINED 


***** OUTPUT / RESULT LIST ***** 


NUMBER TEXT 

1 ANALYTICAL EXPPsESSION OF THE NETWORK 

2 LIST OF OMS 

3 ALL NECESSARY INFORMATION TO DEFINE THE JOB. 

4 JOB ENTERED INTO THE SUDTASK LIBRARY 


***** CROSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 

M.C.A M.A.B 

M . A . D 
h.B.F 

M.C.C M.3.F 
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LEVEL o 

- COrtPONtNTS OF STftTE ‘N.A 
ESTABLISH THE REQUIRED lEN LIST 


* v ->!.** s^ate descriptions 


STATE 


LONG .NAME AND TEXT 


h,a.a construct ulen list for all I/O ll used 

FROM THE JOB DEFINITION, FORM THE uIST OF lEN USED 
SY THE J3‘J AS INPUT, OUTPUT, OR I NPUT/OUT PUT . 


M.A.B CuNSTrJGT LtN FOR A DIRECTORY SEARCH 

USING THE JLEN AND THE QUALIFYING INFORMATION FRO M 
THE EXECUTION CJMMA-iO (EXPLICITLY GIVEN LR IMPLIED IN 
THE UEFAUl.T SENSE), CONSTRUCT THE NAMES WHICH ARc 
EXPECTEU TO BE FOUND IN THE STL, CL SEARCH. 


ALLOWED TrA.NSITIONS 


FROM STATE 
(c* = ENTRY) 


TO STATE INPUT / OUTPUT / 

(.» = cXlT) CONDITION RESULT 


f»N.A.A N.A.Q 

N.A.8 ^N.B.A 


1 

2 


1 

2 


TRANSITION DIAGRAM 
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N.A * ESTABLISH THE KEQUI^EO LEN' LIST 
(CONTINUED) 




***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 LIBRARY DIRECTORY ENTRY FOR THE JOB WITH EXECUTE 
PERMISSION FOR THIS USER. 

E aUALIFICATION INFORMATION FROM THE EXECUTE COMMAND 


***** OUTPUT / RESULT LIST ***** 


NUMBER TEXT 

1 LIST OF ULEN FROM THE DIRECTORY ENTRY 

2 LiSl OF NAMES SUITABLE FOR A DIRECTORY SEARCH 


***** CROSS REFERENCEO TRANSITIONS ***** 


STATE ■ IS ACCESSIBLE FROM 

N.A, A F.A.O 
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LEVEL 3 

COMPONENTS OF STATE N.=B 
CHECK FOR LEN IN LIBRARIES 


STATE 


STATE DESCRIPTIONS ***** 
LONG NAME ANO TEXT 


N.3.A SEARCH THE. STL FOR REQUIRED LEN 

EXAMINE THE STL DIRECTORY TO FIND THE REQUIRED 
LEN. NO ACCESS PERMISSION REQUIRED 


N.3.B SEARCH THE C-- FOR REQUIRED LEN 

EXAMINE THE CL DIRECTORY TO FIND THE REQUIRED LEN. 
ACCESS PER.-1ISSION MUST 3E INDICATED IN THE LEO FOR THE 
CORRESPONDING USE DURING EXECUTION 


***** ALLOhED TRANSITIONS ***** 


FROM STATE 
(i» - ENTRY) 


TO STATE 
= EXIT) 


INPUT / 
CONDITION 


OUTPUT / 

result 


i»N » 3 » A 


N.3.Q 


N.8.6 

(♦N.C.A 

.♦N.C.A 


1 

2 
3 


1 

2 

3 
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N.8 * CHECK FOR LEN IN LIBRARIES 
(CONTINUED) 


INPUT / CONDITION LIST 


NUMBER ' TEXT 

1 SEARCH LIST OF LEN NOT ALL CONTAINED IN THE STL 

2 SEARCH LIST OF LEN ALL OF WHICH ARE COnTAINEU IN THE 
STL 

3 SEARCH list OF LE ALL OF WHICH ARE CONTAINED IN THE 
CL AND HA\/E PROPER .ACCESS PERMISSION COOES’ 


****»■ OUTPUT / RESJLT LIST 


NUMBER TEXT 

1 LIST OF LEN LOCATED IN THE STL, THOSE YET TO BE LOCATED 

2 LIST OF ALREADY EXISTING LIBF.ARY ENTRIES TO BE USED 
DURING EXECUTION, WITH APPROPIAT.E LINKING INFORMATION. 

3 


CROSS REFERENCEO TRANSITIONS 


STATE IS ACCESSIBLE FROM 

N . B . A N . A . o 
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LEVEL 3 

COMPONENTS OF STftTE N«C 
PREPARE JOB FOR EXECUTION 


STATE DESCRIPTIONS 


STATE LONG NAME AND TEXT 


N.C.A PREPARE LEN FOR ALL OUTPUT AND I/O LE 

PRLPA-IE AHEAD OF EXECUTION ALL THE NAMES (OUALI- 
FIEO AND UNQUALIFIED) FDR THE LE TO BE CREATED DURING 
THE JOS. 0IRECT3RY ENTRIES ARE MADE WITH NO TuXT ENTRY. 


N.C.8 SET UP FIuE LINKAGES 

ACTUAu LOGICAL FILE NAMES USED BY THE OMS MUST -3E 
reconciled with current locations for INPUT LE AND THE 
ACTUAL LINKAGES TO THE.LTE MUST tiE SET UF. 


N.G.C PREPARE THE EXECUTABLE CODE FILES 

THE OM TEXT ENTRIES MAY 3E READY TO RUN OR NEED 
SO^E preparation, but in any CASE THE LOCATION OF TtlE 
CODE MUST D£ KNOWN FOR CONTROL CARD FILL IN. 


N.O.D CREATE CONTROL CAROS FOR THIS EXECUTION 

TAKE All THE EXECUTION 'TIME DEPENDENT INFORMATION 
AND PLACE/3U9STITUTE IT IN THE CONTROL CARD SKELETON. 


allowed TRANSITIONS 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

(<♦ = ENTRY) 

(f = cxin 

CONDITION 

RESULT 

r» N . C . A 

N.G.B 

1 

1 

N.G.B 

N.C.C 

' 2 

c 

N.G.C 

N « C • 0 

3 

3 

N.O.D 

f*N «D • 


4 
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N.C t PREPARE JOB FOR EXEGUTIOM 
(CONTINUED) 


INPUT ./ CONDITION LIST 


NUMBER TEXT 

1 OM NETWORK AND THE LIST OF LEN USED DURING EXECUTION 

2 CORRESPONOANCE list for each OM GIVING THE RELATIONSHIP 
BETWEEN LEN AND LOGICAL FILE NAME USED IN THE 03 

3 OM TEXT cNTRT AND THE CORRESPONDING TEXT LOCATION 
SPECIFICATIONS. 

k COMPETE STATUS ON CONTROL CARO RECORD 


*=>■**»■ OUTPUT / RESULT LIST ***** 


NUMBER TEXT 

1 NAMES OF ALL LE USED FOR THIS EXECUTION 

2 CONSISTENT FILE DEFINITIONS FOR ENTIRE DATA FLOW 

3 EXECUTABLE CODE FILES. 

4 ALL JOB COMPONENTS READY FOR EXECUTIOl^ 


CROSS REFERENCED TRANSITIONS ***** 


STATE IS ACCESSIBLE FROM 


N.C.A 


N.3, A 
N.3. B 
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LEVEL 3 

C0HPONENT3 OF STATE N.U 
INITIATE EXECUTION 


***** STATE OESCRIFTIONS 


STATE L0N3 NAME ANO TEXT 


N.O.A INITIATE EXECUTION 

ISSUE A SGHMANO TO THE OS TO EXECUTE THE CONTROL 
CARD RECORD AND WAIT UNTIL THE EXECUTION CCHMmNJ HAS 
BEEN ACCEPTED. 


ALLOWED TRANSITIONS ***** 


FROM STATE 
= ENTRY) 


TG STATE INPUT / OUTPUT / 

- EXIT) CONDITION RESULT 


i»N .0 . A 


fN.E.A 


1 


1 


TRANSITION DIAGRAM 
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N.D * INITIATE EXECUTION 
(CONTINUED) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

1 SIGNAL FROM THE OS THAT THE JOB EXECUTION COMMAND HAS 
been' accepted ANU THE JOB IS EXECUTING. 


***** OUTPUT / RESJLT uI3T ***** 


NUMBER 


TEXT 


1 


CROSS REFERENCED TRANSITIONS ***** 
STATE IS ACCESSIBLE FRO '1 


N.O. A 


N * C . D 
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LEVEL 3 

COMPONENTS OF STATE N.E 
SUBTASK STEP EXECUTING 


***** STATE OESCRIPTICNS 


STATE LONG NAME AND TEXT 


N.E.A SUBTASK STEP EXECUTING 

SOME ARBlTRARir PORTION OF THE -SUoTASK STEP IS NOW 
EXECUTING AND INDICATES NO RCaUlREMENT FOR USER OR IPAu 
EXECUTIVE INTERACTION. 


***** allowed transitions ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

(r» = ENTRY) 

(c = EXIT) 

CONDITION . 

result 

(♦N.E.A 

r* 0 • A 

1 

1 


0 • c 

2 

2 


TRANSITION DIAGRAM 
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N.E t SUBTASK STEP EXECUTING 
(CONTINUED) 

INPUT / CONDITION LIST 

NUMBER TEXT 

1 INPUT REQUEST COMMAND FROM THE STS 

2 OUTPUT COMMAND FROM THE STS 

****’>■ OUTPUT / RESULT LIST »■**** 

NUMBER TEXT 

1 TERMINAL INPUT REQUEST 

2 terminal OUTPUT REQUEST 

***** CROSS REFERENCED TRANSITIONS ***** 

STATE IS ACCESSIBLE FROM 

W*t*A Nau*A 
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LEVEL 3 

COMPONENTS OF STATE Q,C 
PURGE A CL ENTRY 




STATE 


STATE □ESGRIPTIONS ***** 
LONG NAME AND TEXT 


ORIGINAL PAGE Ih 
OE POOR QUALTTYi 


Q • * A 


RETRIEVE DICTIONARY ENTRY 


Q.G.B RETRIEVE JiRLCTORY ENTRY 

THE SJDTASK ID LIST MUST BE EMPTY BEFORE A PURGE 
CAN BE EFFECTED. 


U.C.C TRACE 'JEPENuENCIES 

THE DICTIONARY AND DIRECTORY ENTRIES ARE CHECKnD 
FOR DEPENDENCIES. IF THE USEU-3Y LIST IN THE DICTIONARY 
IS NOT EMPTY THE DEPENDENCY CHAINS ARE TRACED. THE Sdd- 
TAS.< ID LIST IN THE DiRECTDRY ENTRY MUST ALSO EE EMPTY 
before a purge is PERMISSIBLE. 


G.C.D PUBLISH rjE>^ENuENCY LIST 

A COMPLETE LIST OF AL.. DEPENDENT LIBRARY ENTRIES 
AND THE 0Wi4ER OF EACH IS PUBLISHED 


Q.G.E SET STATUS 

THE STATUS IS' SET - ^PURGE REQUESTED^ IF UEPERD- 
ENGIES HERE FOUND. STATUS IS SET = ♦PURGED'^ IF DATA IS 
RELEASED FROM DATA 3ASE. 


Q.C.F PURGE DATA 

RELEASE DATA FROM TEXT OF LE» 
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ORIGINAL PAGE Ih 
OF POOR QUALITY 

Q,C « PURSE A CL ENTRY 
(CONTINUED) 


***** STATE DESCRIPTIONS (CONTINUED) ***** 


STATE . . long name AND TEXT 

Q.C.G CLEAR rCEFERENCES 

REFERENCES IN EXISTING LIBRARY ENTRIES WHICH SHOW 
PURGED LE AS A USER ARE CLEARED. 


Q.G.H Clear directory entry 

THE DIRECTORY ENTRY IS CLEARED OF ALL INFCRMATIuiJ 
EXCEPT NAME, TYPE, FINAL STATUS RECORD. 



allowed transitions ***** 


FROM STATE 

TO state 

INPUT / 

OUTPUT 

(c* = ENTRY) 

(i* = EXIT) 

CONDITION 

RE SUL r 

f»Q.C.A- 

Q . C . D 

1 

1 

Q , C . J 

Q • C . C 

Z 

1 

Q * ^ . C 

Q.C.O 

3 

z 


Q.C.F 

4 

1 

U.G.D 

Q.C.E 

5 

3 

Q » C . E 

Q.C.H 

9 

1 

U.C.F 

Q.C.G 

7 

1 

Q.C.G 

Q.C.E 

o 

1 

Q.G.H 

f»F; A. A 

10 

1 
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LEVEL 3 TRANSITION DIAGRAM 
STATE Q.C: PURGE A CL ENTRY 


A134 


Q.C * PURGE A CL ENTRY 
(CONTINUED) 


***** input / CONDITICh LIST ***** 


number text 

1 DICTIONARY ENTRY RETRIEVED 

2 DIRECTORY ENTRY RETRIEVED 

3 DEPENDENCIES FOUND 

k NO DEPENDENCIES FOUND 
5 LIST OF DEPENDENCIES PUILISHED 

7 DATA FROM TEXT ENTRY RElEASEU FROM DATA CASE 

8 ALU REFERENCES TO PJRGE-J L£ CLEARED FROM DATA BASE 
B STATUS SET = ♦PURGED’- 

13 DIRECTORY ENTRY CLEARED OF All CUT FInAl STATUS 


****^ OUTPUT / RESJLT LIST ♦♦♦♦♦ 


NUM3ER TEXT 

1 

2 ERROR MESSAGE 

3 ERROR CONDITION TO BE CLEARED 
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LEVEL 3 

G0HP0NENT3 OF STATE H.C 
CONSTRUCT DICTIONARV ENTRY 


state OESCRIPTIONS ****’>■ 


STATE LONS NAME AND TEXT 


W.C.A RETRIEVE SDU FOR DICTIONARY 

THE SQD FOR L£ TYPE DICTIONARY IS RETRIEVED FOR 
USE IN SUBSEQUENT PROCESSING. 


W.C.B ENTER DICTIONARY INFORMATION 

THF. USER ENGAGEb X A DIALOGUE WITH THti SYSTEM 
DURING WHICH THE INFORMATION FOR THE DICTIONARY ENTRY 
IS PROViOEO. 


W.C.C REVIEW ENTRY 

THE NEW DICTIONARY ENTRY IS DISPLAYED TO AND RE- 
VIEWED BY THE USER. 


W.G.O ADD ENTRY TO DICTIONARY 

THE NEW ENTRY HAS BEEN APPROVED bY THE USER AND 
IS ADDED TO THE DICTIONARY- IN THE DATA 3ASE 


W.G.E ERROR RECOVERY 

RESOLUTION OF A CONFLICT OVER AN ENTRY IN A CL 
DICTIONARY IS MADE, AN ENTRY HAVING SAME NAME,1YPE WAS 
MADE BY ANOTHER USER IN THE TIME INTERVAL AFTER THE 
FIRST CHECK HADE AT THE TIME DIALOGUE BEGAN AND THE 
TIME THE USER WAS READY TO ADD THE ENTRY, 


W.G.F SAVE ENTRY TEXT IN SL 

THE USER HAS BEEN UNABLE TO SATISFACTORILY RESOLVE 
A NAME- CONFLICT AND SAVES THE ENTRY LOCALlY. 
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W.C : CONSTRUCT OICTIONART ENTRy 
< CONTINUE J ) 



ALLOWEG TRANilTiONS ^=f-*** 


FROH STATE ' 

TU 3TAT-E 

INPUT / 

OUTPUT 

(!* = ENTF.y) 

= EXIT) 

CONDITION 

RESULT 

r* W * • A 

W • C ■ c5 

1 


. C . [i 

rt.C,3 

2 

2 


IH *C >C 

4 

4 

W .G.G 

W » C • 3 

5 

4 


N.C.Q 

6 

4 

W • 0 * u 

i*F . A , A 

7 

e. 

r* W * * E 

i*F . A« A 

i: 

1 


vj • C • u 

c 

4 


H • C • F 

5 

4 

W . C . F 

r*F » A 1 A 

12 

4 

X 


W .C . F 

11 

? 
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W.C I CONSTRUCT 
(CONTINUED) 


OICTIONARK ENTRY 


ORIOIKAI; PAGE IS 

Qp POOR quAiot 


***** INPUT / condition LIST ***** 


NUN3ER TEXT 

1 SDJ FOR DICTIONARY RETRIEVED 

2 USER/SYSTEM DIALOG INCOMPLETE 

k DICTIONARY ENTRY COMPLETE SUT NOT APPROVED 

5 USER WANTS TO MODIFY ENTRY 

5 DICTIONARY ENTRY COHPLeTe AnO APPROVED 

7 ENTRY ADDED TO DICTIONARY 

i NAHE CONFLICT RESOLVED 

9 CONFLICT N3T REioL VED-USER wAnTS TO SAVE ENTRY TEXT 
LOCALLY 

10 USER WANTS NO FURTHER ACTION ON THIS ENTRY 

11 USEK/SYSTEN DIALOGUE SPECIFYING LUCAl SAVE OF TEXT 

12 ENTRY SAVED IN SL AS SPECIFIED BY UWER. 


***** OUTPUT / RESULT LIST ***** 


NUMBER 


TEXT 


1 

2 MESSAGE TO USER REQUESTING MORE INFORMATION 
4 DICTIONARY ENTRY TEXT IN USER WORKING AREA 
6 UPDATED DICTIONARY AvAILADlE IN DATA dA3£ 
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LEVEL 4 

COMPONENTS OF STATE I.C.8 
ENTER CODING MODULE 


***** STATE QESCRIFTION3 ***** 


STATE LOtNG NAME AND TEXT 


I.C.8. A CHECK LI3RARY ENTRY ' 

THE APPROPRIATE LIiPA<Y DIRECTORY IS SEARCHED FOR 
A COOING module HAVING THE SAME NAME. IF ONE IS FOUND 
AN ERROR CONDITION EXISTS AND IS REPORTED. 


I.C.8. 8 CHECK UICTIlNARY ENTRY 

THE APPROPRIATE OiCTICNARY IS SEARCHED FOR A PRE- 
VIOUSLY MADE DEFINITION, IF WORKING IN THE CL AND ONE 
IS FOUND IT IS OFFERED FUR REVIEW. IF IN THE CL AND NO 
DICTIONARY ENTRY EXISTS, ONE MUST 8E MAGE. IF IN THE 
STL THE DE IS OPTIONAL, 


I.C.8.C REVIEW OlCriDNARY ENTRY 

USER MAY DESIRE TO EXAMINE EXISTING DEFINITION FOR 
CORRECTNESS. IF A CHANGE IS DESIRED HE ENTERS THE 
MODIFY DEFINITION MODE VIA A PAUSE, 


I.G.d.D 


DEFINE CM 


A DEFINITION FOR THE NEW CM IS ENTERED (A DICTION- 
ARY ENTRY MADE) 


8.E 

RETRIEVE SCO 

8.F 

REPORT ERROR 

8.G 

construct cm 


FOR CM 


THE SOURCE CODE AND AUXILIARY DATA WHICH COMPRISE 
THE LIORARY ENTRY FOR THE CM ARE ENTERED 
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I.C.B I ENTER COOING MODULE 
(CONTINUED) 



allowed TRANSITIONS ****->■ 


FROM STATE ' 

TO STATE 

INPUT / 

OUTPUT / 

(f» = ENTRY) 

(r» = EXIT) 

CONDITION 

RESULT 

r*X*0»B*A 

X « C * 3 0 A 

1 

1 


I.C.B. 3 

15 

7 


I .C.B.F 

a 

2 


r*I .C.K 

A 

7 

I .C. b.i3 

I .C . d • C 

5 

5 


I.C.3.0 

6 

4 


I .C.-3.E 

7 

k 

I .G. 8.C 

I.C.3.E 

0 

k 

I .c.a.o 

I . C . B . 0 

10 

A 


I.C.3.'E 

9 

A 


I .C.B.F 

11 

5 

I *G • 3* E 

I • G . 8 * 

Ifa 

7 

I .C.B.F 

.♦1 .C.M 

3 

7 

X • G • 8* G 

I . C . 8 . F 

lA 

6 


I . C . B . G 

15 

u 


I . C . L 

12 

7 
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I.C.B I ENTER COOING MODULE 
(CONTINUED) 


INPUT / CONDITION LIST 


NUMBER TEXT 

1 A CM WITH SAME NAME AS NEW CM FOUND IN LI3RARY 
Z AM3IGU0U5 CM NAMES NOT RESOL\/ED 

3 ERROR CONDITION POSTED 

A NO PREVIOUS LE FOR CM C/ISTS 

5 PREVIOUS DICTIONARY ENTRY EXISTS 

6 NO DICTIONARY ENTRY EXISTS AND ONE IS REQUIRED OR 
D tSIRED 

7 NO DICTIONARY ENTRY EXISTS AM ONE NOT REQUIRED OR 
W ANTED 

• 3 • DICTIONARY ENTRY APPROVED 

D DICTIONARY COMPLETE AND IN DATA CASE 
iJ MORE INFORMATiO^I RE lUlREO TO COMPLETE DICTIONARY ENTRY 

11 IMPOSSIBLE TO COriPLETL DICTIONARY ENTRY 

12 AuL DATA FOR CM lE ACQUIRED 

13 MORE DATA REQUIRED FOR i.E 
• lA IMP.OSSidLE TO COMPLEfE lE 

15 ‘ DIRECTORY ENTRY FOR NEW LE EST.aBLISHED Ih USER WORKING 
AREA. 

1-6 SOD RETRIEVED 


OUTPUT / RESJLT LlSJ 


NUMBER TtXT 

1 MESSAGE TO USER GIVING OPO?.TUNlTY TO REMOVE AMBIGUITY 

2 ERROR MESSAGE (AMDIGJOUS CM NAME) 

3 TEXT OF OICTIGNARY ENTRY AVAluABi.E FOR DISPLAY 
‘t MESSAGE INFORMING USER TO PROCEOE 

5 ERROR MESSAGE (DE NOT COMPLETED) 

6 ERROR MESSAGE (LE NOT COMPLETED) 

7 
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LEVEL k 

COMPONENTS OF STATE I.C.C 
ENTER DATA SET 


STATE DESCRIPTIONS ♦♦♦♦♦ 


STATE LONS NAME AND TEXT 


T.C.C.A RETRIEVE STORED DATA OEFINiTIOM 

THE USER WANTS TO CREATE AN INSTANCE CR OCCURRENCE 
OF A DATA SET BY ENTERI'iG VALUES FOR VARIABLES GUNTAIN- 
EO IN THE DATA SET. SUBSEQUENT PROCESSING REQUIRES AN 
SOO. IF THERE IS NO SDO IN HIS. STL DR IN THE CL WHICH 
THE USER HAS PERMISSION TO USE AN ERROR CONDITION IS 
ESTABLISHED PREVENTING CCNTIMJATIOn AT THIS POINT. 


I.C.C.B CONSTRUCT TEaT FDR NEW LE 

THE USERS DATA IS ACCEPTED, T RANbFOP.MFU , FORMATTED 
AND PREPARED FOR STORAGE FOLLOWING SPEC IF IC ATIONS CON- 
TAINED IN THE SDO. THE DATA MAY "COME FROM THE TERMINAL 
OR FROM OTHER ORIGINS EXTERNAL TO IPAO SUGh AS HAGNcTIC 
TAPE, PUNCHED CAROS, DISK FILES, AS iNOICATcO BY THE 
USER. DATA FROM SEVERAL SOURCES HAY BE GGMEINEO. 


I.C.C.C REPORT ERROR 

SOME ERROR GONOITIOH5 MAY OCCUR AFTER MUCH VAL- 
UABLE PROCESSING HAS OCCURRED IN WHICH CASE THE USER 
MAY ELECT TO SAVE THE DATA ENTERED FOR lATER CCRRECTXON 
VIA MODIFY. 
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I.C.C I ENTER DATA SET 
(CONTINUED ) 


♦ aLlOweo transitions 


FROM STATE 
(.♦ = ENTRY) 


TO STATE 
(f = EXIT) 


INPUT / 
CONDITION 


OUTPUT / 
RESULT 


r*I*C*C«A 
I.G.C.B 
1*1 .C.G.C 


I.C.G. B 
i .C.C.C 
-♦I.C.K 
I . C . C . 0 
I • c • c • u 
cI.C.L 
'* !■< C • L 
I* I • C • H 


5 
2 
1 
4 

6 
b 
7 
d 


1 

2 


1 

5 


TRANSITION DIAGRAM 



'2 


6 / 


tH fO tH 



I.C.C t ENTER DATA SET 
(CONTINUEa) 


input / CONDITION LIST 


NUMBER text 

i STORED DATA DEFINITION CORRESPONDING TO NEN LE EXISTS 
I SOD DOES NOT EXIST 

3 QIRECTOKY ENTRY FOR NEW LE ESTABLISHED IN USER WORKING 
AREA 

4 DATA INPUT AND LE CONSTRUCTION INCOMPLETE 

5 LE CONSTRUCTION COMPLETE IN USER WORKING' AREA 

6 IMPOSSIBLE TO PROCESS SOME SPECIFIC INPUT OATa 

7 USER DESIRES TO SAVE DATA SET AS IS 
3 ERROR CONDITION TO 3E CLEARED 


***^>i- OUTPUT / RE3JLT LIST 


NUM3ER 


TEXT 


1 

2 tRROR MESSAGE (SOD DOES NOT EXIST) 

3 MESSAGE REOUESTING USER TO ENTER MORE DATA 

4 ERROR MtSSAGE (DATA Pr.OCESSiNG EkROR) 

5 APPROPRIATE ERROR CODE 
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LEVEL 4 

COMPONENTS OF 3T4TE I.C.O 
■ ENTER STORED OATA DEFINITION 


+ STATE DESCRIPTIONS 


STATE LONG NAME AND TEXT 


I.G.D.A CHECK LIDRARY ENTRY 

THE APPROPRIATE LIBRARY DIRECTORY IS SEARCHED 
FOR AN SDD HAVING THE SAME NAME. IF ONE IS FOUND AN 
ERROR CONDITION EXISTS AND IS REPORTED, 


T.O.D.O CHECK DICTIONARY ENTRY 

THE APPROPRIATE DICTIONARY IS SEARCHED FOR AN 
EXISTING DEFINITION, IF -FORKING IN THE DL AND ONE 
IS FOUNU IT IS OFFERED FOR REVIEW. IF WORKING IN 
THE CL AND NO DICTIONARY ENTRY EXISTS, ONE HUST BE 
MADE. IF IN THE STl THE DE IS OPTIONAL. 


I.C.D.C REVIEW DIDTICNARY ENTRY 

USER MAY DESIRE TO EXAMINE EXISTING OEFINITION 
FOR CORREGTi<£SS, IF A CHANGE IS DESIRED HE ENTERS 
THE MODIFY OEFIiMlTION MOOL VIA A PAUSE 


I.G.O.U DEFINE SDD 

A DICTIONARY ENTRY FOR THE DATA SET IS MADE. 


I.G.D.E RETRIEVE SDD i-ORSDO 

THE SDD WHICH SPECIFIES THE STRUCTURE IN WHICH 
ALL STORED OATA DEFINITIONS ARE STORED IN IPAD IS 
R£TRI£VE"D. 


I.C.O.F REPORT ERROR 
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I.C.O i ENTER STORED DATA OEFI^aTXON 
(CONTINUED) 


***** STATE DESCRIPTIONS {CONTINUED) ***** 


STATE 


LONG NAME AND TEXT 


I«o«0*G CONSTRUuT iOD’" 

THE INFORMATION WHICH SPECIFIES THE CONTENTS 
AND ORGANIZATION OF THE DATA SETS FOR WHICH THIS 
SOD IS TO BE USED IS ENTERED ANO A LE OF TYPE SOD 
CONSTRUCTED. 


***** 

ALLOWED TRANSITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT 

(r* = ENTRY) 

= EXIT) 

CONDITION 

RESULT 

r^I .C.U.A 

I .C.U.A 

1 

1 


I « G » D ♦ D 

15 

7 


I .C .u .F 

2 

2 


I* I . C . K 

<+ 

7 

I .C.0.8 

I. C.D.C 

5 

3 


I .C.U.D 

6 

4 

■ 

l.C.D.E 

7 

4 ■ 

I .C.D.C 

I. C.O.E 

8 

4 

I . C . 0 . 0 

I.C.0.0 

10 

4 


I. C.O.E 

9 

4 


I.C.D.F 

11 

c: 

I .C.O.E 

I .C.D.G 

16 

7 

I . C . D . F ' 

1* I . C . H 

3 

7 

I * * D . G 

I * C . D . i* 

14 

6 


I . C « U . ^7 

13 

4 


t* I • C . L 

12 

7 
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LEVEL 4 TRANSiTlON DIAGRAM 
STATE I.C.D : ENTER SDD 


A149 











I.C.D * ENTER STORED DATA DEFINITION 
(CONTINUED) 


INPUT / CONDITION LIST 


NU-'iSER TEXT 

1 AN SOD WITH SAME NAME A3 NEW SDQ FOUND IN LIBRARiT 

2 AMBIGUOUS NAMES NOT RESOU/EO 

3 ERROR CONDITION POSTED 

k NO PREVIOUS LE for 3DD EXISTS 

5 PREVIOUS OICTlONARf CNTR^T EXISTS 

6 NO DICTIONARY ENTRY EXISTS ANJ ONE IS REuUlREJ OR 
DESIRED 

7 NO DICTIONARY ENTRY rXISTs AND ONE IS NEITHER Rt- 
QUIRcO NOR WANTED. 

d DICTIONARY ENTRY APPROVED 

9 DICTIONARY COMPLETE AND IN DATA >JA:iE 

13 MORE INFORMATION REQUIRED TO COMPLETE DICTIONARY ENTRY 

11 IMPOSSIdLE TO COMPLETE DICTIONARY ENTRY 

12 ALL DATA FOR SDJ ACaUlREO 

13 MORE DATA FOR SOD REUUKED 

m IMPOSSIdLE TO COMPLETE lE FOR NE*< SJD 

15 DIRECTORY ENTRY FOR NEW l£ ESTABLISHED Ir4 USER WORKING 
AREA 

16 SCO FOR SOJ RfcTRIEVEO 


*»■**»- OUTPUT / RESULT LIST 


NUMBER TEXT 

1 MESSAGE TO USER GIVING OP'PCRTUnITY TO REMOVE AMOIGUiTY 

2 ERROR MESSAGE (AMdIGJOUS SJD NAME) 

3 TEST OF DICTIONARY ENTRY AVAILABLE FOR JISPlAY 

4 MESSAGE INFORMING USER TO PkOCEEO 

•3 ERROR MESSAGE (OE NOT COMPLETED) 

6 ERROR MESSAGE (LE NOT COMPLETED) 

7 
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LEVEL 4 

COMPONENTS OF STATE I.C.E 
ENTER OICTIONARif 


*‘^**»- STATE DESCRIPTIONS ***** 


STATE LONG NAME AND TEXT 


I.C.E. A CHECK uIBRARY ENTRY 

THE USER CAN ONi_Y DEFINE NEW DICTIONARIES FOR HIS 
STL, TWO OICTiONARIES FOR STL VARIABLES AND LIBRARY 
ENTRIES ARE GIVEN DEFAUlT NAMES EQUAL TO THE CL DICT- 
lONARY NAMES WITH SUoTASK ID APPENDED. THE USER IS FREE 
TO OEFINE additional DICTIONARIES TO SUIT HIS OWN NEEDS 
OUT THE DEFAULT DICTI ON ARIES ARE USED FO'? SJd TASKS IN A 
MANNER ANALOGOUS TO THE CL USAGE. 


I.C.E. .8 ’ CHECK DICTIONARY ENTRY 

THE local 3R Sl DICTIONARY IS CHECKED FOR PREVIOUS 
DEFINITION OF NON-DEFAUlT NAH-U DICTIONARY. 


I.C.E.C 

REVIEW DICTIONARY ENTRY 

I.O.E.O 

OEFINE NEW DICTIONARY 

I .C.E.E 

RETRIEVE SOD FOR DICTIONARY 

I.C.E.F 

REPORT ERROR 

X « 1/ • E • ^ 

CONTRJCT DICTIONARY 




j t. 


, I 
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I.C.E I ENTER DICTIONARY 
(CONTINUED) 




FROM STATE 
(.* = ENTRY) 

1*1 .C.E.A 


I .0 .E.B 

JL • G • E • C 
I . C • £. D 


I .G.E.E 
I.G.E.F • 
I .G.E.G 


ALLOWED TRANSITIONS 


TO STATE 

INPUT / 

OUTPUT / 

(,* = EXIT) 

CONDITION 

RESULT 

I .C.E. A 

i 

1 

I .C.E.O 

15 

7 

I.C.E.E 

7 

4 

I.G.E.F 

2 

2 

cI.C.K 

4 

7 

I.C.E.C 

5 

3 

X . G . £ . D 

6 

4 

X « 0 . C- . E 

a 

4 

X *C *E . D 

13 

4 

I.C.E.E 

9 

4 

I .C.E.F 

11 

5 

X . G . . G 

16 

7 

1*1 .G.H 

'3 

7 

X . L* * c . h 

14 

6 

X. G.E.G 

13 

4 

f*X .C .L 

12 

7 


ORIGINAK PAGE;® 
OB' POOR QUMOT 
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LEVEL 4 TRANSITION DIAGRAM 
STATE UC.E : ENTER DICTIONARY 


A153 


I.C.E t ENTER OICTIDNARir 
(CONTINUED) 


*’*0® IS 

^OOR QUAU!^ 


***** input / condition list ***** 


NUM3ER TEXT 

1 A OICTIONAR/ WITH SAME NAHE AS NEW DICTIONARY FOUND IN 
STL 

2 AM3IGU0US DICTIONARY NANES NOT RESOLVED 

5 ERROR CONOITION POSTED 

•+ NO PREVIOUS LE FOR DICTIONARY 

5 PREVIOUS DICTIONARY ENTRY EXISTS 

6 NO DICTIONARY ENTRY EXISTS 

7 USER WANTS DEFAULT NAMEJ LE DICTIONARY 

3 DICTIONARY ENTRY APPROVED 

3 DICTIONARY ENTRY COMPLETE AND IN DATA BASE 

LI MORE INFORMATION REQUIRED TO COMPLETE DICTIONARY ENTRY 

11 IM-^OSSIBLE TO COMPLETE DICTIONARY ENTRY 

12 ALi_ DATA FOR DICTIONARY lE ACaUIRED 

13 MORE DATA REOUIRED FOR Lt 

14 IMPOSSIBLE TO COMPLETE lE 

15 DIRECTORY ENTRY FUR NEW LE ESTABLISHED IN USER WORKING 
AREA 

lo SUO RETRIEVED 


***** OUTPUT /. RESULT LIST ***** 


NUMBER 


TEXT 


1 MESSAGE TO USER GIVING OPPORTUNITY TO REMOVE AMBIGUITY 

2 ERROR MESSAGE . (AMBIGUOUS DICTIONARY NAME) 

3 TlXT OF DICTIONARY ENTRY ( DEFINING NEW DICTIONARY) IS 
AVAIi-ABLE FOR DISPLAY 

4 MESSAGE INFORMING USER TO PROCEED 

5 ERROR MESSAGE (DIRECTORY ENTRY NOT COMPLETED) 

6 ERROR MESSAGE (LX3RARY ENTRY NOT COilPLETEO) 

7 
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LEVEL 4 

COMPONENTS OF STATE I.C.J 
ENTER DATA CONTROL DATA 


STATE GESCRI?riONS 


STATE LONG NAME ANO TEXT 


I*C*J*A RtTklhUE GOD 

THE SUJ FOR THE SYSTEM DATA STRUCTURE WHICH HCL03 
THE SECURITY, ACCESS OATA IS RETRIEVEU FOk USE IN THE 
PROCESSING OF THE INPUT DATA 


I.C.J. 3 CONSTRUCT TfcXT 

THF CONTRGi. UATA IS ACCEPTED, PROCESSED AND PRE- 
PARED FOR STORAGE. 


I.C.J.C REPORT ER<Ox 

All error CONOITIOnIS cNCOUNTEREO IN THIS STATE ARE 
FATAL. PROCESSING IS AJORTED. 


ALLOWED TRANSITIONS 


-ROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

(r» = ENTRY) 

(f» = EXIT) 

CONOITrON 

RESULT 

r»I .G. J, A 

X ft C . 0 . 0 

3 

1 


I.C.JftC 

2 

2 


r* I ftC ftK 

1 

1 

I . u . J o 3 

I ft C ft J ft 0 

4 

3 


I ft 0 ft J ft C 

5 

4 


r»I ftC ftL 

6 

1 

I .0. J.C 

t*I .C.M 

7 

5 



OF POOR 

PA.GB TS 
QUAiJni 
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LEVEL 4 TRANSITION DIAGRAM 


STATE I.CJ : ENTER DATA CONTROL uATA 




I.C.J I ENTER DATA CONTROL DATA 
CGONTINUEQ) 


***** INPUT / CONDITION LIST ***** 


NUMBER TEXT 

i SOD FOR SirSTEH LE TlfPE DCU EXISTS 
a SOD DOES NOT EXIST 

S DIRECTORY ENTRY FOR CONTROL DATA LE ESTABLISHED IN USER 
WORKING area 

A DATA INPUT AND lL CONSTRUCTION INCOMPLETE 

5 IHPOSSleLE TO PROCESS SOME SPECIFIC INPUT DA,TA 

6 LE GONSTPJCTICN COHPuETE IN USER WORKING AREA 

7 ERROR CONDITION TO BE CLEARED 


***** OUTPUT / RESULT LIST ***** 


NUMBER TcXT 

L 

a ERROR MESSAGE 

3 MESSAGE RECUESTING USER TO ENTER MORE DATA 
■* ERROR MESSAGE 
5 APPROPRIATE ERROR CODE 
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LEVEL 4 

COMPONENTS OF STATE K.8.A 
MOOIFT CH 


****>!■ STATE OESCiilPTIONS 


STATE long name AND TEXT 

K.-3.A.A RETRIEVE STORED DATA DEFINITION 

THE 3JD FOR A CM 13 RETRIEVED FOR USE IN FOLLOWING 
PROCESSING, 

K.d.A,8 PERFORM Cl MODIFICATIONS 

THE USER ENGAGES IN DIALOGUE WITH THE SYSTEM TO 

CARRY OUT HIS CHANGES. 

K.3.A.C REPORT ERROR 


allowed transitions ***** 


FROM STATE 
(H = ENTRY) 


TO STATE INPUT / OUTPUT / 

(r* = EXIT) CONOITIGiM RESULT 


hK.D.A.A 

K.3.A.B 

t^K .D.A.C 


K « S ♦ A * S 
K • 8 » A • <3 
K . 8 • A . C 
(♦K • C .A 
I* K ♦ C .A 


1 

2 
4 
3 
6 


1 

2 

3 

1 

1 
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K.B.A * MODIFr CM 
(CONTINUED) 


transition diagram 



QDAIJtji'- 



INPUT / CONDITION LIST 


NUM3ER TEXT 

1 SOD FOR CM RETRIEVED 

^ MODIFICATIONS INCOMPLETE 

3 MOOIFICATIONS COMPLETE 

4 ERROR CONDITION ENCOUNTERED DURING MODIFICATION 

5 ERROR CONDITION CLEAREO 


OUTPUT /- RESULT LIST 


NUH3ER TEXT 

1 

2 MESSAGE TO USER REQUESTING ADDITIONAL DATA 

3 ERROR MESSAGE 
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LEVEL 4 

COMPONENTS OF STATE K.8.B 

MODIFY OM o 


***** state DESCRIPTIONS ****^ 


STATE long name AND TEXT 

K.6.B.A RETRIEVE SOD FOR OM 


K.d.e.a 


PERFORM O'l hCOIFiCATIONS 


K.d.e.C 


REPORT ER<OR 


ALLOWED TRANSiTIJNS 


FROM STATE 
(r» = ENTRT) 


IG STATE INPUT / OUT 

{*♦ = EXIT) CONDITION RES 


!*K.d.d,A 

K.3.B.3 

r*K#'3*H*C 


X . d .0 , u 
K . d . 3 . 3 

f*K.C. A 
;*K.C. A 


i 

E 

k 

J 

6 


1 

2 

3 

1 

1 


TRANSITION DIAGRAM 
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C 13 


K.8.8 t MODIFY OM 
(CONTINUED) 


INPUT / CONDITION LIST ***** 


NU-i^iER TEXT 

1 SDO FOR OM RETRIEVED 

2 MODIFICATIONS INCOMPLETE 

5 MGQIFICATIONS COMPLETE 

<* ERROR CONOITION ENCOUNTEREU DURING MODIFICATION 

6 ERROR CONOITION CLEARET 


***^* OUTPUT / RESULT LIST ****^ 


NUM3ER TEXT 

1 

2 MESSAGE TO USER REQUESTING AuJITIONAL DATA 

3 ERROR MESSAGE 
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LEVEL 4 

COMPONENTS OF STATE K.B.C 
MODIFY JOB 


STATE DESCRIPTIONS 


STATE LONG NAME AND TEXT 


K.B.C. A RETRIEVE SDO FOR JOB 


K.-3.C.3 PERFORM J J3 MODIFICATIONS 


K.3.C.C REPORT ERRO^ 


ALuONED TRANSITIONS 


FROM STATE 1C STATE INPUT / OUTPUT./ 

(i* = ENTRY) (c* = EXIT) CONDITION RESULT 

f*K.3.G.A K.cJ.C.B 

K.3.C.B K.B.C.3 

K . B . L> • C 
I* K . U .A 

(♦K.3.C.C f»K.G.A 


1 1 

2 2 

4 • o 

3 1 

6 1 


TRANSITION DIAGRAM 
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K.B.C * MODIFir JOS 
(CONTINUED) 


INPUT / CONDITION LIST 


NUM3ER TEXT 

1 SOO FOPs JOS RETRIEVED 

2 MODIFICATIONS INCOMPLETE 

3 MODIFICATIONS COMPLETE 

ERROR CONDITION ENCOUNTERED DURING MODIFICATION 
6 ERROR CONDITION CLEARED 


♦♦♦«» OUTPUT / RESULT LIST ^**** 


NUMSER TEXT 

1 

2 MESSAGE TO USER REQUESTING ADDITIONAL DATA 
J ERROR MESSAGE 
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LEVEL 4 

COMPONENTS OF STATE K.8.0 
MODIFY OS 


STATE DESCRIPTIONS 


STATE LONG NAME AND TEXT 


K.3.D.A RETRIEVE SOD FOR DATA SET 

MODIGiCATIONS ARE TO DE MADE TO A USER DEFINED 
DATA SET AND THE CORRESPON JI NG SOD IS RETRIEVED FOR 
USE IN THE SUBSEQUENT PROCESSING. 


K.d.D.8 PERFORM DATA SET M ODIFICATI ONS 


K.3.D.C REPORT ERROR 

***** ALLOWED TRANSITIONS ***** 


FROM STATE 

TO STATE 

INPUT / 

OUTPUT / 

{<♦ = ENTRY) 

((* = EXIT) 

CONDITION 

RESULT 

CK.3.D.A 

K.B.D.3 

1 

1 

K.3.0.B 

K.B.O.B 

2 

2 


K • B • U • o 

4 

"7 



i 

1 

»>K.8.D.C 

« C ■ A 

6 

1 


TRANSITION DIAGRAM 
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K.B.O 1 HODIpy OS 
(CONTINUED) 


INPUT / CONDITION LIST **^*‘f^ 


NUN3ER TEXT 

1 SDG FOR 03 RETRIEVED 

2 rtOQIFICATIUNS INCOMPLETE 

3 MOOIFIGATIONS COMPLETE 

i+ ERROR CONDITION ENCOUNTERED DURING MODIFICATION 

6 ERROR CONDITION CLEARED 


OUTPUT / RESULT LIST 


NUM3ER TEXT 

1 

2 MESSAGE TO USER REQUESTING AUDIT IONAl DATA 

3 ERROR MESSAGE 
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aPPENDIX B 


DSTaiLBD PROBLEM SOLVING HODEL 


B.l GENERAL WORK FLOW 

The design procedures in Volume II are representative of 
the type and organization of tasks necessary to accomplish the 
design of an aircraft. However, a computer system designed only 
to perform the tasks shown in Volume II in the sequences given 
would have limited value. A generalization of the design 
procedure into basic elements is needed so that the design of 
the computing system will support the development of a wide 
range of air and space craft. The work organization presented 
in Volume II has been divided into five basic activities. These 
activities, and their relationship, are shown in figure B.l. 
Each of the nodes in figure B.l should be looked upon as 
actions. The nodes are defined as follows: 

PLAN The determination of objectives and constraints 

which define a desirable product and the development 
of a plan of activities to achieve these objectives 
within the constraints. 

PREPARE Setting up to do work. 

MODIFY Altering preparations to do work when it can be done 
without changing the plan. Generally, this is due 
to contingencies which are minor relative to the 
overall plan. 

WORK The activity which aims directly towards completion 

of a meaningful step in the plan. 

REPORT Recording and/or making visible the results of WORK 
and determining if the planned work is done. 

The work flow diagram shown in figure B.l. was used to make 
the following observations: 

a) Entry can be made at any node; however, activity in 
preceding nodes affecting the entry node must have 
been completed. 

b) The nodes are coupled; i.e, activity in a node is 
directly affected by the quality of the information 
coming to it from a preceding node. 
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Figure B. { General Work Flow 


c) fill nodes are not connected to all other nodes, nor do 
all connecting lines. have double arrowheads. Examples 
are: 

1) 90BK always terminates in a BBPOET with a return 
to PLfiN. This preserves accountability and 
management control. 

2) There is no direct connection going from PL£N to 
tfOSK bypassing PREPARE. Doing so would encourage 
resource waste and ineffectiveness in WORK. 

3) MODIFY always results from an attempt to PREPARE 
to do WORK. The result of MODIFY is either that 
a change can be made and PREPARE continue without 
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affecting PLAN or that an error or weakness has 
been exposed in PLAN that must be corrected 
before PREPARE can continue. 

d) The flow diagram can be applied to a single person or 
a group of persons. Some nongualitative . observations 
on efficiency can be made. For example, working only 
within the WORK node is the mark of an undisciplined 
individual and a poorly managed organization. Working 
without the REPORT node signifies a lack of personal 
or supervisory review of work progress relevant to the 
plan. 

These considerations are typical of human planning and 
organizing functions. The IPAD system will work compatibly 
within this environment. 

A study was also made of how product development is 
generally organized. It was found that there is a hierarchy of 
planning and management control as shown in figure B.2. There 
is a flow of information through the levels of the hierarchy 
with each level essentially summarizing the level below and 
providing feedback about the direction of work. The labels of 
company, product, etc. , are somewhat arbitrary. The terms in 
the parenthesis are basic descriptors of the primary interest at 
each level. These descriptors are only representative and are 
not accurate for all organizations. There are, however, several 
common characteristics. 

a) There is a level at which real work on the product 
design is accomplished by the user. Above that level, 
the activity is planning and management control. 
Below that level, the work is preparation of tools and 
methods. In the hierarchy shown in figure B.2, real 
work on the product is at the sub task level. 

b) The user at a particular level tends to transmit 
information above him and desire action below him. 

c) Those above the user are interested in what is being 
done, those below the user are interested in h ow 
things are done, while the user concentrates on . the 
actual doing, varying his interest between w ha t and 
how depending on the immediate situation. 

d) The number of levels shown in figure B.2 is not 
uniquely six, but it is neither large nor small 
compared to six. 
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Some further comments on a) are useful. In general terms, 
there are activities that relate to thinking, planning, and 
preparing criteria from which to work. In figure B.2, these 
activities are included in working out the product description, 
refining the description into a group of tasks that signify 
areas of responsibility, and further refining each of the tasks 
into subtasks that signify actual work packages. Once the work 
package is defined, activity centers around collecting and 
defining tools and methods into packages with which to perform 
the work. This latter activity is called a "job" in figure B.2. 
If the tools or methods do not exist or have to be modified, 
another class of activity is required called an "activity" in 
figure B.2. From these considerations, the IPAD system should 
be formulated around a principal work activity called a subtask 
and that all other activities support or relate to working on a 
subtask. 


WHAT 

k 


INFORMATION \ 

• COMPANY (Profit) 

, T ' 

USER 

^ 

• PRODUCT OR PROJECT (Marketing) 
A • TASK (Technology) 

\ ® SUBTASK (Discipline) 

'T 

. ACTION 

\ O JOB (Programs & Data) 

\ « ACTIVITY (Computer Features) 

1 

HOW 


Figure B.2 Organizational Hierarchy of Product Design 
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Figures B.3 through B.7 are an expansion, of each node of 
figure B.l. ■ For example, figure B.3 is an expansion of PLAN 
with the unexpanded nodes, HODIFY, PSEPARE, WORK and REPORT, 
appended to show connectivity. 

The following definitions will be helpful in reading the 
flowcharts and descriptions: 

Objective - The result to be achieved from a design 
activity. 

Constraint - A bound placed on a design activity as a 
limit or assigned value. 

Report - The collection of objectives and constraints 

which, when satisfied, will describe and 
specify the product design and serve as. a 
basis for judgement on the success or 
quality of intermediate design activities, 
(This is distinct from the verb "REPORT” 
used as one of the nodes of the work flow 
model, ) 

Other definitions are given in section 4.0 of volume IV’, 


B.2 "PLAN" NODE DEFINITIONS - Figure B.3 

Node 1 - DEFINE Product into Tasks 

DEFINE is a general node meaning refinement of an 
existing definition by dividing it into subparts; for 
example, in this case, dividing a product development 
program into several tasks. Hence, this define is a 
description of the desired product objectives and all 
the major work tasks necessary to achieve these 
objectives. The results of this definition need to be 
available for review, revision, and comparison 
throughout the product development period. This, and 
other similar information generated in later DEFINE 
blocks, is compiled in a record which serves as a 
continuing source of direction. 
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Node 2 


Node 3 


Node 4 
Node 5 

Node 6 
Node 7 

Node 8 


- ERROR? 

A YES choice in an error branch means an inconsistency 
was found during refinement in the previous DEFINE 
that requires reconsideration of a higher level 
DEFINE. In practice, the ERROR box at Node 2 probably 
does not exist because the implications of a YES 
choice at this level are too far reaching. Any 
changes in the original product definitions would have 
been corrected prior to compiling the record in Node 
1 . 

DEFINE Tasks into Subtasks 

See Node 1 definition. Tasks are divided into 
subtasks. Note that an error found in Node 8 may 
force a redefinition in Node 3. This is primarily a 
dependent variable problem that would not exist if the 
tasks were independent. Subtask definitions are 
characterized by a record of objectives and 
constraints. A subtask appears to be the basic level 
at which meaningful work on the product is done. The 
objective in PXAN is to identify the necessary 
subtasks closely enough so that scheduling and 
resource requirements can be estimated and to assure 
that a workable set of activities has been defined. 

- ERROR? 

See Node 2 definition. 

- Initial Planning? 

The dividing line between planning and actual work on 
the product design is at the subtask level. There may 
be a division in the PLAN activity centered around 
this distinction. During initial planning, some 
critical subtasks may be planned in detail, i.e. , 
while others may be left until the work actually 
begins. 

Select First Subtask (s) 

Thera will be many subtasks. Critical ones may be 
selected for initial planning, others left for later. 

- DEFINE Subtasks into Jobs 

The relationship between the subtask definition and 
the tools and methods available to do the work is 
established here. Within IPAD, this activity usually 
means collecting and assembling computer programs into 
working packages. See Node 1 definition also. 

- ERROR? 

See Node 2 definition. 
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Node 9 - DEFINE Jobs into activities 

Specific computing technigues enter into the planning 
at this level. Any job’ involving computational tools 
already developed and tested need not enter into this 
level of planning. Typically, the non-computing user 
would only work in this level during the original tool 
planning and specification phase. This is the typical 
level at which computer programming and system design 
support will be utilized. 

Node 10 - ERROR? 

See Node 2 definition. 

Node 11 - Select Next Task 
This is either 

a) a return from REPORT at the completion of a task 
with the intent of beginning a new task, or 

b) a return from MODIFY with the conclusion a 
subtask is unworkable and must be redefined at 
the task level- 

Node 12 - Evaluate and Select Next Subtask 

This is a return from REPORT after subtask completion 
and before task completion. The completed results of 
this subtask are evaluated against the task plan to 
determine if the results of the subtask are 

satisfactory and what the next subtask is. 

Nods 13 - Subtask Already Defined 

If the review at Node 12 introduces an unplanned 
subtask, a redefinition at the task level is reguired. 

B. 3 "PREPARE" NODE DEFINITIONS - Figure B.4 ’ 

Nods 1 - Sit Down 

"Sit Down" is the activity of addressing ones self to 
performing a job. It expresses the act of focusing 
attention to a relatively narrow field of potential 
accomplishment that can be completed in hours or days 
as opposed to weeks or months. That is, the time span 
for completion is small compared to the total task and 
very small compared to the product. Generally, the 
job is capable of being accomplished through the 
primary involvement of one user. 
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Figure B.4 An Expansion of PREPARE 
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Node 2 


Node 3 


Hods 4 - 


Nods 5 - 


Node 6 - 


Hay T? 

Given the user has some plan of action, he then 
proceeds to initialize. Initialization generally 
consists of collecting all the data and capability the 
user understands to be pre-requisites to starting. 
The user knows in principle what data, computer 
programs, sequences, etc., is needed. He must now 
package specific items and in so doing determines 
availability, adequacy, permission requirements, etc. 

Can I? 

While "Hay I?" concentrates on availability, general 
adequacy, and authorization; "Can I?" emphasizes 

workability. That is, "Will the program execute on my 
hardware?"; "Sill sequential computer programs 
interface data automatically?"; etc. If the user has 
complete control over his tools, this step diminishes 
in importance. When the user is utilizing tools 
developed and controlled elsewhere, this step can be 
of commanding importance. 

Determine Unsatisfied Requirements 

Any requirements not previously identified must be 
satisfied before continuing. 

Job Impossible? 

The gob may be threatened by any of the following: 

a) Requesting access without permission. 

b) Requesting access to nonexistent information. 

c) Illogical relationships in planning not 
identified until now. 

The problem is resolved by either taking an alternate 
equivalent route dr by modifying the plan. 

Revise Question 

Local variations in PLAN implementation are possible. 
This box allows for such a variation (provided it does 
not change the basic plan) , as well as for the 
conclusion that the user asked a bad question. 
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B.4 

Noie 


Hole 

Node 

Node 

B.5 

Node 


Node 


••aODIFY” NODE DEFINITIONS - Figure B.5 

1 - Can I Redefine Job? 

The current job is not executable and somehoir must be 
altered if the subtask is to be continued without 
compromise. Sufficient information is required to 
avoid an unnecessary NO answer to this question, and 
be clear about why the job is impossible in its 
current state. A self teaching system would be useful 
here. 

2 - Redefine Job 

The full power of job construction and modification 
must be available at this point. 

3 - Can I Redefine Subtask? 

Because the current job execution is not possible, the 
subtask definition is threatened, A NO answer to this 
question means a review of basic plans. 

4 - Redefine Subtask 

The remarks under Node 2 apply here. Redefining the 
subtask may or may not require job redefinition. 

"WORK” NODE DESCRIPTIONS - Figure B.6 

1 - Execute 

Activities in this box tend to be associated with 
computation in the general sense. Upon completion of 
this box, the user expects results from which subtask 
or task decisions will be made. To the scientific 
user this is where the "floating point arithmetic" 
takes place. The distinction between some activities 
done in WORK and those done in PREPARE can be user 
dependent. For example, FORTRAN compilation could be 
done in either place. This node is where the primary 
use of the central processing unit occurs. All 
technical code will execute in this box, 

2 - Interaction Required? 

The user may need to interact with an executing 
computer program to query certain parameters, alter 
sequences, stop execution, test optimization 
convergence, etc. Any type of control that is not 
exercised through the technical code falls into the 
category of system code interaction. 
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Figure B.5 An Expansion of MODIFY 
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Node 


Node 

Node 


B.6 

Node 


Node 


3 - Perform Interaction 

In this activity, the user inserts his judgment and 
control into the execution sequence. Activity status 
needs to be maintained while interaction takes place. 
The point at which interaction will take place is 
specified at the time of interaction without having to 
alter the initial execution plan. The physical and 
logical interface characteristics are all important 
and must support any aim the user may have in desiring 
interaction. 

4 - All Interactions Complete? 

5 - Continue Current Job? 

When interactions are complete, the current job may or 
may not be useful. If yes, restart must be able to. 
take place. If no, the option must be available to 
continue the job at a later time. 


"REPORT” NODE DESCRIPTIONS - Figure B.7 

1 - Save Job and Subtask Data 

Since the current job is not to be continued at the 
moment, restart data may need to be retained for 
restart at a later time. Whatever has been completed 
in this job needs to be logged on the subtask record 
sheet unless the user desires an elimination of all 
job effects and accomplishments. All data_saved must 
be sufficiently labeled to avoid ambiguity and 
confusion later on. Time and date are minimal 
components in this identification. 

2 - Save Task Data 

This implies a knowledge of task data as opposed to 
subtask or job, which implies a knowledge that a task 
exists. Thus some kind of task plan must be visible 
in the system, or at least identifiers of task level 
data that can be matched must exist. This can be 
extremely important when data from one sufatask feeds 
another subtask. Otherwise a user could invoke a job 
where execution is dependent upon data sets not yet 
generated. 
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Node 3 - 


Nods 4 

Node 5 
Node 6 

Nods 7 
Node 8 


Tabulate Results for Task Report 

Assuming that the report is defined and carried over 
from PLAN, any subtask data that is also part of the 
task report should be identified and logged so that 
■the degree of report completion is clearly observable 
on a timely basis. 

- Subtask Complete? 

A subtask plan must be available (even if it is only 
a mental picture) before this question can be readily 
answered. A NO answer implies that the user is now in 
the middle of an interrupted subtask, trying to follow 
a path to allow restart of the subtask. 

Task Complete? 

Similar to Node 4. 

Issue Task Report 

Report generation capability is clearly needed here. 
Each item in the report needs to be threaded to the 
data which contributed to the item. The report should 
have several levels of detail, depending upon the 
level within figure B.2 to which it is issued. 

Product Complete? 

Similar to Node 4. 

Issue Product Report 
Similar to Node 6. 
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. Figure B.8. I An Expansion of the Total Work Flow Model 
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APPENDIX C 


NIGRATION OF IPAD SOFTWARE 


A special study was conducted by the Control Data 
Corporation as a subcontract of the Boeing IPAD contract, to 
investigate the problems of; 

a) migrating applications programs and the IPAD system 
software from a 3rd generation computer to a 4th 
generation computer within a computer family and 

b) migrating applications programs and IPAD system 
software across 3rd generation computer families. 

The following is the final report of their study. 
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SUMMARY AND CONCLUSIONS 

A solution of the general IPAD problem (Section 1.1) includes, as one of its 
principal parts, development of methods for moving operational modules (OM’s) 
freely among the various computers in the IPAD system. Since most of the OM’s 
are written in some form of FORTRAN, a solution for this case alone can be 
expected to be useful. 

A number of methods for solving this migration problem, at least in principle, 
are examined in Section 1.2. Of these, only two showed sufficient promise to 
be retained for further consideration. The first. Method 1, requires that each 
source language program be translated to a common language before compilation 
and execution. The second. Method 3 in the original list, is based on a pairwise 
set of source - host translators. The principal advantage of Method 1 is that 
the common language becomes, by definition, the IPAD standard. The advantage 
of Method 3 is that its initial cost is probably lower, but as new dialects enter 
the system, new translators must be written, and documentation standards would 
be, difficult to enforce. Method 1, thus appears, on balance, to be the preferred 
choice, and is accordingly recommended. 

The design of the common IPAD language is the next concern. Three require- 
ments are basic. It must be possible to translate existing programs to it, the 
translated programs must not contain machine dependent code, and the language 
must be extensible to accommodate fourth generation computers entering the 
IPAD system. 

As a preliminary step, two FORTRAN dialects, one for CDC computers and the 
other for IBM computers, are examined in detail and differences in syntax and 
usage noted (Section 2 ). Syntax differences are numerous, but do not constitute 
a serious translation problem, since the intended interpretation for the source 
code is known, and the corresponding statements in the host language can be 
constructed from this knowledge. Several examples of this syntax conversion 
are given in Section 2.8. 

A more difficult problem arises out of the interaction among the program, the 
job control language, and the compiler. Fortunately, the areas in which this 
problem are most likely to arise are known, and even if translation cannot be 
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carried out automatically, the suspect parts of the program can be flagged for 
programmer examination. 

The most difficult translation problem occurs when code adhering to a common 
FORTRAN syntax makes use of machine dependent constants or variable values, 
since here there may be no indication that the code is machine dependent, and 
therefore, there is nothing for the translator to detect. Even here, however, 
there are constructions in which this problem is more likely to occur, and these 
too can be flagged for review. The conclusion that follows is that much of the 
translation process can be automated, but a substantial residue remains for 
hand translation, and the signficant problems are the detection of machine inde- 
pendent code and then fathoming of the programmer’s intent. 

It follows from examination of FORTRAN dialects in current use that the common 
IPAD language can be machine independent only if it requires that much detail 
that is now implicit in the computer environment for which the program was 
written be specified explicitly. Accordingly in the proposed common language, 
IPADF (Section 3), it is required that all variables be declared, either explicitly 
or by class, together with their lengths in appropriate units. The collating 
sequence must either be given explicitly, or fixed once and for all. (The decision 
here was left open, pending further study). Explicit reference to overlays is 
banned, but it may be desirable to allow declaration of variables by level in a 
presumed hierarchy of storage. 

To allow for extension of the language to the new class of vector and string 
processors IPADF allows elementary arithmetic and logical operations on one 
dimensional arrays, but not on subsets of declared arrays. This rationale 
allows operations favoring fourth generation computers that can still be 
implemented readily on third generation machines. 

More extensive vector and string operations analogous to those available as 
primitive functions in APL are reserved for IPADFV, the fourth generation 
IPAD FORTRAN, which contains IPADF as a subset. The architectural differ- 
ences between third and fourth generation machines is so fundamental that it can 
be assumed that most OM's will in time be reprogrammed for the newer com- 
puters. Consequently, IPADFV is not expected to be introduced un til fourth 
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generation machines have effectively replaced their predecessors. An example 
illustrating this reprogramming is given in Section 4. 3. 

The conclusion reached in this study is that the IPAD software migration 
problem is best solved by translating current OM’s into, and writing all future 
OM’s in a common machine independent FORTRAN based language, IPADP, 
developed especially for IPAD, that can be extended to include vector and string 
processing in its fourth generation version, IPADFV. 
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IPAD SOFTWARE MIGRATION 


1. 0 THEORECTICAL BACKGROUND 
1. 1 The General Problem 

The IPAD software migration problem can be stated as follows; given an 
open-ended set of programs, called Operational Modules (OMs), written in 
several languages for different computers, design a machine independent 
system, IPAD, in which the OMs are linked by an executive program through 
a data management subsystem to a common data bank. The system should 
execute as a job in batch mode under the standard operating system at any 
installation having the minimum equipment configuration required. 


1.2 Language Conversion 

Suppose that m different source languages are represented among the OMs 
and that IPAD must execute on n different host computers. If d of the source 
languages are also languages for the host computers, then mn-d source 
language to host machine language conversion algorithms will be required. 


Most scientific programs (in the United States at least) are written in some 
form of FORTRAN. It will be assumed, therefore, that the OMs are all 
written in a dialect of FORTRAN and that each source and host computer is 
provided with a compiler for converting programs to its own machine code. 


Now let - 

L. be the i^^ FORTRAN dialect 

M. be the j machine language 


P(A,L.) be a program for algorithm A expressed in 

P(A,M.) be a program for algorithm A expressed in M 
D 


j 


IJ & j 

C.j be a compiler for converting programs from L^ to M^ 


Also let A — B j — C denote the execution of program B with input A and 
output C. 
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With this notation, a software migration process can be described concisely. 
For example - 


P(A,Lp^ 


P(T. .,M ) 
J-n r 






^■P{D,U^) 


In words, algorithm A written in is translated to L^. in machine r to 
produce a program for the modified algorithm B. The new program is 
compiled on machine s yielding a machine language program for yet another 
modification of the algorithm which can be executed on machine k. In real 
processes, r and s normally belong to the set (j, k), but it is not necessary. 
Nor is it necessary that A, B, and D be the same algorithm. Indeed, there 
is no general way to decide if they are or not, except at the machine language 
level where the outputs of a program and its translation can be compared. 

In what follows, however, it will be assumed that the algorithm is carried 
unchanged through the steps of a migration process, unless deliberately 
altered. 


The migration process sketched in the example above can be partitioned in 
three different ways, depending on whether j = o, i, or k. 


Method 1. i == o. For this case, each source language program 
is translated to a common language, L^, before 
compilation. Schematically - 


P(A, L.) 


P(Ti^.Mp 


P(A.Lo) 






Here, m translators Tj^^ and n compilers are required. 


Method 2. j = i. Since T^ is equivalent to the identity translation, 
this method simplifies to - 


P(A, L.) _» |P(C.^, M^) P(A, M|^) 


and requires mn-d compilers. 


Method 3. j = k. Here - 


P(A, L.) 


P(Tij^,M^) ^P(A,L^)_^P(C,j^,M^) 


h,P(A,M^> 
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This method requires ixin-d translators, but makes use of 
the already existing host language compilers. 

If t represents the cost of a translator, and c the cost of a compiler, then 
mt + nc, (mn-d)c, and {mn-d)t are the cost functions for these three methods 
respectively. The relative ranking of these cost functions depend, of course, 
on the values assigned the parameters. However, under the plausible 
assumptions that (i) d=o, (ii) m + n < mn> and (iii) t < c, it is easy to see 
that Method 2 is more costly than either Method 1 or Method 3. Accordingly, 
it will be dropped, at least for the time being, and Methods 1 and 3 retained- 
for further consideration. 


One other method merits introduction at this time, 
for converting programs from M. to M.. Then - 

J 


Let ly be an interpreter 


Method 4. 


P(A,L ) _^P(C ,M ) _^P(A,M ) JP(I ,M ) L_^P(A,M ) 

I I Zii si— _ ' J 


This method requires mn-d interpreters. 


Sometimes translation and execution are combined, so that each instruction 
in M^ is translated as needed, yielding - 

Method 4a. 


P(A, M. ) 



.R 


1. 3 A Model Language Converter 

It will be useful to have at hand an idealized model of a converter which can 
represent, in turn, a translator, compiler, or interpreter. Suppose the 
conversion to be performed by a finite state machine defined by the two 
functions 

Y(i + 1) = [S(i), x(i), Y(i)l 

and 

S(i + 1) = ^ [s(i), x(i), Y(i + 1)] 
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where x(i) is the current character from the input source language text, Y(i) 
is the current (possibly empty) sequence of output characters of the converted 
text, and S(i) is a vector defining the current state of the machine. The 
converter, thus, can be conceived as a black box that accepts the source 
text, one character at a time, and after a certain number have been received, 
depending on the state, issues a string of one or more characters of the 
converted text. For certain combinations of input and machine state, con- 
version may not be possible, and Y(i + 1) will be issued as an error message. 

In the simplest case, well-defined (as to beginning and end) substrings of 
input text are replaced by substrings of output text, where a one-one corres- 
pondence exists between the two strings.. In the worst case, the complete 
input text must be received by the converter before the first character of the 
converted text is emitted. 

In general, conversions will range between these extremes. Well-defined 
substrings (called here sentences ) are presented to the converter in sequence. 

As each sentence is received, it will have 0, 1, or many conversions. 

If the input sentence has no conversion, and is a syntactically correct sentence 
of the input language, it denotes an action of the source computer that cannot 
be expressed in the output language, either (i) because of a shortcoming in 
that language, or (ii) because no comparable action exists for the host machine. 
In either case, a special message is inserted in the output text. 

If an input sentence has just one conversion, the corresponding output sentence 
(or sentences) is issued. 

If an output sentence has more than one translation, it must be saved until 
sufficient text is accrued to resolve the ambiguity. 

1. 4 Problems of Language Conversion 

There are a number of problems associated with the design of a practical 
converter. The main task is to establish a correspondence between the 
sentences of the source and host languages. Most sentences in most languages 
are ambiguous when taken by themselves. In FORTRAN, statements (sentences) 
are made up of a fixed part and a variable part (which may be empty). The 
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fixed part serves to identify the class to which the statement belongs, and, in 
fact, is a sort of distributed name for that class. If the variable part is absent, 
the statement cannot be ambiguous; it will either have exactly one meaning, or 
none. On the other hand, the variable part, when present, is composed of 
parameters whose values in a given program may be determined by the charac- 
teristics of the source computer; i. e. , the statement may be machine dependent. 
If every statement containing parameters needs to be analyzed in its {often 
unbounded) context to ascertain its true meaning, the conversion task, if not 
inipossible, becomes one of truly formidable proportions. 

Despite the fact that many FORTRAN statements are potentially ambiguous, 
most statements actually appearing in a pair of FORTRAN programs written 
in different dialects are identical in form and have almost the same meaning. 

Of the remainder, most involve merely syntax differences, in which again 
essentially the same meaning is expressed in another way. The residue, 
comprising only a small part of the source program, requires the most effort, 
and here the difficulty lies more often in detection of the anomaly than in its 
correction. 

While similar statements in the Source language generally have close to the 
same meaning as in the host language, they are seldom identical, due to 
differences in the computer's word lengths, data representation methods, 
memory organization, etc. When a statement has a different meaning for the 
host machine than for the source machine, a decision must be taken as to which 
meaning the converted text is to carry. If the host computer's interpretation 
is accepted, the statement and its conversion are identical. If the source 
language interpretation is to be preserved, the converted text becomes a set 
of directions for reproducing the source machine action on the host computer. 

In the latter case, conversion reduces to imitation (emulation or simulation) 
of the source computer on the host machine. This is essentially Method 4 above. 
The advantage is that conversion is exact. The disadvantages are that (i) writing 
an interpreter for one computer in the language of another Is not a simple task, 
and (ii) simulation of one machine on another leads to very inefficient program 
execution. 
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1. 5 Comparison of Conversion Methods 


It is obvious from the analysis so far, that the major problems of program 
migration lie not so much in the differences between FORTRAN dialects as in 
the differences between the source and host computers. Even if they used a 
common language, programmers writing for different computers would produce 
different programs. 


As can be seen, each of the methods so far described has advantages and dis- 
advantages. Method 1 is attractive from the standpoint that a common language 
for IPAD would impose a standard FORTRAN on all source programs. Pre- 
existing code would be converted to it, and all new programs would be written 
in it. The major disadvantage is that it is still possible to write machine 
dependent code in a common language, and the temptation to do so would be 
as strong as ever - namely, to improve performance on one's own computer. 

A priori. Method 2 appears to have little to recommend it. The writing of a 
new compiler, or the rewriting of an already existing one to provide for different 
dialects is on the face of it more difficult than making the conversion at the 
source language level. Method 3 does just that, and it should be more cost 
effective than Method 1. However, without a common language and an official 
version of each program, uniform standards of program documentation and 
maintenance would be difficult to enforce. Method 4 has the advantage that 
conversion is exact, but execution is inefficient - again there is no common 
language. 


An interesting, but expensive possibility, denoted Method 5 provides for a 
common language as in Method 1, and allows as an option, the exact conversion 
of Method 4. 


Method 5. 


P(A, L.) 



Here, if d=o, m translators, m + n compilers, and mn interpreters are needed 
for the full system. 
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The advantage of a common language is expected to be decisive for IPAD users, 
and in what follows, the emphasis will be placed on conversion by way of Method 
1, but much that will be said will apply to the other methods as well. 


1. 6 Implementation of Language Converters 

While not strictly necessary, it is of some advantage that the conversion pro- 
cesses themselves be machine independent. This is not as easy to achieve as it 
might at first appear. Suppose it is required that all conversion programs be 
written in a common implementation language. Then a corripiler is needed for 
each target computer. By hypothesis, this condition is fulfilled if FORTRAN is 
chosen for this purpose. But this approach must be handled carefully to avoid 
machine dependencies creeping into the conversion code, since it is just as easy 
to write machine dependent conversion programs as OMs. For example, for 
Method 1, the implementation process is represented by 


P(C M^) 


where is the source FORTRAN dialect, is the common IPAD FORTRAN, 
and L^. is a machine independent subset of (e.g. , ANSI FORTRAN). 


Another approach that reduces the labor of creating a special implementation 
language compiler makes use of a two stage process. Here a simple bootstrap 
compiler, written either in machine independent FORTRAN, or in the 

assembly language of the target machine k, is compiled and then used to compile 
the second stage compiler, written in language L^. ^^ 21 ^ is a macro pro- 

cessor for the macro language Lg. The converter (translator, compiler, or 
interpreter) is written in and compiled by This is essentially the method 

of STAGE 2 [1] . Schematically, 
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A macro processor provides a reasonably efficient way to resolve syntactic 
differences between a pair of languages, since in principle, all that is required 
is the substitution of one string of characters for another. The fixed part of the 
first string is a template representing the distributed macro name. The macro 
body generates a new fixed part, inserts parameters to replace those from the 
original string, and produces the replacement string. 

Either method solves the context-free conversion problem. When a syntactic 
unit (sentence, statement) of the input text can have more than one meaning, 
depending on the context in which it is embedded, the problem becomes more 
difficult. By way of illustration, suppose the following subroutine was written 
to be executed on the CDC 6600, which is capable of storing 10 6-bit alpha- 
numeric characters in one 60 -bit word. It is desired to translate this routine 
for compilation and execution on a computer in which 8 -bit alphanumeric 
characters are stored four per word. 

SUBROUTINE PACK 

C THIS ROUTINE READ IN AN 80 COL CARD INTO AN ARRAY IN 
C WHICH THE CHARACTERS ARE STORED, ONE PER WORD, RIGHT 
C ADJUSTED WITH ZERO PILL. THE CHARACTERS ARE THEN PACKED 
C INTO 8 WORDS, 10 TO A WORD. 

DIMENSION IN (80), lOUT (10) 

READ 1000, IN 

1000 FORMAT (80 Rl) 

I = 1 

DO 10 J = 1, 8 
lOUT (J) = 0 
DO lO K = 1, 10 

lOUT (J) = IN (I) + lOUT (J) * 64 
10 1=1 + 1 

PRINT 1001, lOUT 

1001 FORMAT (A 10) 

RETURN 

END 

The only dialect statement in the subroutine is the first format statement, yet 
nearly half the statements are machine dependent and, therefore, ambiguous. 
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The translator can detect and replace the dialect statement although the details 
of implementation may not be simple. For example, replace - 
1000 FORMAT (80R1) 

with 

1000 FORMAT (80A1) 

CALL PATCH (IN) 

and insert 

SUBROUTINE PATCH (IN) 

DIMENSION IPT (64), JPT (64) 

DO 10 I = 1, 80 
DO 5 J = 1, 64 

IF (IN(I).EQ.IPT(J) GO TO 10 
5 CONTINUE 
10 IN (I) = JPT (J) 

IPT and JPT are preset with a data statement to the character set left adjusted 
with space fill, and right adjusted with zero fill, respectively. 

What the translator cannot do without considerable analysis, is detect that the 
indices on both DO-loops in the original program are machine dependent. The 
detection and conversion of machine dependent code is the central problem for 
automatic language translation and will be discussed more fully in subsequent 
sections of this report. 

1. 7 Preliminary Remarks on a Common Language for IPAD 

Method 1 requires that all programs be translated to a common machine inde- 
pendent FORTRAN dialect, called here, IPADF. 

At the syntax level, a language is just a set of rules for stringing the symbols of 
an alphabet together. At the semantic level, a language is a method for recording 
and communicating information. The two aspects of language are joined by the 
process of interpretation, whereby symbol strings generated by a set of syntax 
rules are assigned meanings. It is easy to see that a symbol string can be given 
more than one interpretation, so that fixing the syntax is not sufficient to fix the 
interpretation. As any student knows, there is no way to infer the meaning of a 
word in a strange language by just looking at it. If it can’t be found in a dictionary. 
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its meaning must be determined by observation of the response it evokes in a 
user of the language. 

The interpretations given FORTRAN statements vary among users. The 
relevant response to an interpretation is the action taken by the user's computer, 
and that response is determined by the compiler. Thusj it is not always 
possible to know what a statement in a FORTRAN program means without 
knowing the computer on which the program is to run and what the compiler does 
in translation. This is clearly unsatisfactory for IPADF whose statements are 
intended to be interpreted in just one way. 

While it is not possible to structure a language in a way that compels the user 
to adopt the intended interpretation, it is possible to develop the syntax in a 
way that will make it easier for him to do so. It is most important that the 
language be rich enough so that useful concepts can be given explicit statement. 
This means that if it is customary for a user of one machine to interpret a 
FORTRAN statement differently than a second user does, the statement must 
be replaced with a pair of statements, one for each interpretation. Thus, it 
turns out that a machine independent language is of necessity richer in detail 
than one specialized to a single computer. 

Following an examination of two well known FORTRAN dialects in Section 2, the 
main features of a machine independent IPAD FORTRAN are described in 
Section 3. 
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2.0 FORTRAN SOURCE CODE TRANSLATION ON THIRD GENERATION 
COMPUTERS 

It is expected that IPAD will be implemented first on conventional third genera- 
tion computers with later transfer to fourth generation vector processors. For 
both Method 1 and Method 3 of the preceding section, translation from one 
FORTRAN dialect to another is required, either to a common language (Method 1), 
or between pairs of source-host dialects (Method 3). In either case, the feasi- 
bility of translation must be demonstrated. 

In this section, two well known FORTRAN dialects are examined, FORTRAN 
Extended for the CDC 6000 series computers, and FORTRAN IV (H Extended) 
for the IBM 360 series computers. For convenience, the former will be called 
CDCF, the latter IBMF. 

Neither language includes the other as a subset. Each contains statement forms 
peculiar to it, some denoting extensions to the basic FORTRAN language, others 
included to utilize certain machine features, and others representing little more 
than variations in syntax. 

The catalogue of differences between CDCF and IBMF given below were obtained 
by comparing the respective reference manuals [^2] , [sj ,and do not include 
deviations introduced by the compilers. - 

2. 1 Features In CDCF Not In IBMF 

(2.1.1) ENCODE-DECODE (allows data moves in main memory under 
format control) 

(2.1.2) Implied DO-loops in data statements 

.(2.1.3) Data initialization in labelled COMMON by DATA statements 
outside a BLOCK DATA subprogram 

(2. 1.4) Two branch arithmetic and logical IF statements 

(2. 1.5) Literals and octal constants in arithmetic statements 

(2.1.6) Masking expressions (permits use of logical operators on 
non-logical variables) 

(2. 1. 7) Abbreviated subscripts on arrays, and abbreviation of logical 
symbols 

(2. 1. 8) Left and right justified literal constants with zero fill 
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2.2 Features in IBMF Not In CDCF 

(2.2.1) IMPLICIT type declaration by initial letter ’ . 

(2.2.2) Maximum of seven subscripts in array declarations 

(2.2.3) Data initialization in type declaration 

(2.2.4) GENERIC statement (allows function calls by generic name) 

(2.2.5) IXimmy variables on ENTRY statements 

(2.2. 6) List directed I/O (allows data transfers formatted by separators) 
(2.2.7) Call-by-name for subroutine variables 

2. 3 Syntax Differences Between CDCF And IBMF 



Element 

CDCF 

IBMF 

(2. 3. 1) 

comment 

C, or $ in col. 1 

C in col. 1 

(2. 3.2) 

string delimiter in 
FORMAT statements 

-1' 

T 

(2.3. 3) 

maximum name length 

7 characters 

6 characters , 

(2.3.4) 

alphabetic symbol set 

A - Z 

A - Z. $ 

(2. 3. 5) 

PAUSE n 

n (octal) 

n (decimal) 

(2.3.6) 

END 

termination program 

does not terminate 
program 

(2.3. 7) 

TYPE in type 
declarations 

optional 

no 

(2.3.8) 

computed GO TO 
out of range 

abort 

CONTINUE 

(2.3. 9) 

assigned GO TO 
out of range 

go to absolute 
address 

abort 

(2.3. 10) 

RETURNS declaration 

SUBROUTINE SUB, 
RETURNS (A, B) 

SUBROUTINE SUB 
(*,*) 

(2.3.11) 

Complex argument in 
IF statement 

real part taken 

not allowed 

(2.3. 12) 

PROGRAM statement 

yes 

no 

(2. 3. 13) 

NAMELIST 

$ NAME 

& NAME 



$ 

& END 


2. 4 Machine Dependent Statements In CDCF And IBMF 

(2.4. 1) type ECS in CDCF (identifies variable in Extended Core Storage) 
(2.-4'. 2) type *S statements in IBMF 

(2. 4. 3) Any other FORTRAN statement in which the value of a parameter 
depends on .the word length of the machine, the collating sequence, 
or the way in which memory is organized. 
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2 . 5 In put /Output And Data Transfer Statements In CDCF And IBMF 

(2.5.1) Asynchronous read -write 
CDCF 

BUFFER IN (a,p) (A, B) 

BUFFER OUT (a,p) (A, B) 

IF (UNIT(a))r, s,t 

a is data set number, p is parity mode. A, B first and last 
address in main memory; r, s,t are respectively, unit ready, 
end-of-file detected, parity error. 

IBMF 

READ (a, ID=n) 

WRITE (a, ID=n) 

WAIT (a, p) list 

a is data set number, n is identifier, list defines area in main 
memory, and is either an array name or first and/or last 
address. If list is not specified on READ, a record is skipped. 

(2.5.2) Random access 
CDCF 

OPENMS (a, ix, d, p) open mass storage file 

READMS (a, fwa, n, i) read mass storage file 

WRITMS (a, fwa, n, i) write mass storage file 

STINDX (a, ix, 1) store index 

a is data set number, ix is first word address of index, 1 is 
index length, p is parity mode, fwa is first word address of 
record, n is number of words to be transferred, and i is the 
record number or address of record number (name). 

IBMF 

DEFINE FILE a (m, r, f, v), . . . 

READ (a'r, b, ERR=c) list 
WRITE (a'r, b, ERR=c) 

FIND (a'r) 

where a is data set number, m is number of records in data 
set, r is maximum size of each record in a, f is the format 
control, and v is the pointer to the record involved in the 
current operation. 
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2. 6 Implementation Restrictions In lEMF'And CDCF 


There are no uniform standards restricting the range of most FORTRAN para- 
meters. As a result, part of the definition of the language is left to implementive 
decisions which may or may not be documented. For example, in IBMF, the 
following restrictions are imposed: 


( 2 . 6 . 1 ) 
( 2 . 6 . 2 ) 
( 2 . 6 . 3 ) 

(2.6.4) 


DO-loop nesting is limited to 25 levels 

31 

The test value in a DO- statement may not exceed 2 - 2 

No more than 255 characters allowed in a literal constant or in 
a field in a FORMAT statement 

Up to 50 nested references to another statement function can be 
made in the definition of a statement function. 


In CDCF, 

(2.6.5) DO-loop nesting can extend to 50 levels 

15 

(2. 6. 6) The test value in a DO- statement may not exceed 2 

(2. 6. 7) A literal in an expression is limited to 10 characters; in a DATA 

statement, the length cannot exceed 19 continuation cards; in a 
FORMAT statement, 136. 

(2. 6. 8) The number of nested references to other statement functions is 
undocumented; up to 63 arguments are allowed. 


2. 7 CDCF And IBMF Interfaces With Job Control Language 

There exists a close relationship between a version of FORTRAN in use with a 
given operating system, and that system's job control language. In a general 
way, the algorithm is described in FORTRAN, and the manner of execution in 
a given computer system is specified in the job control language. The distinction 
is not precise, and in some systems run time specifications are made in 
FORTRAN that in other systems are given in the job control language. In CDCF, 
for example, overlays can be defined and called explicitly in the program. In 
the IBM- system, overlays are defined in the job control language, and called 
implicitly in the program. Again, CDCF requires that the names of all input/ 
output files be given in a special PROGRAM statement. The IBM system provides 
this information in the job' control language. 
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2 . 8 Translation From IBMF To CDCF 


Now suppose it is desired to translate programs written in IBMF to CDCF. For 
this case, items under 2 . 1 above play no role, except perhaps for optimization. 
Items under 2. 3 are the most common cause of trouble whenever an attempt is 
made to run an IBMF program on a CDC computer without preliminary editing, 
but they are in fact easy to translate since each can be converted as encountered. 

Those features of IBMF having no precise counterparts in CDCF listed under 2.2 
are more- difficult to translate. For example, the IMPLICIT type declaration, 
(2.2.1) IMPLICIT INTEGER A-H requires in CDCF that each variable beginning 
with one of the letters A through H be included in a type INTEGER declaration. 

Arrays having more than three subscripts (2.2.2) must be converted for CDCF. 
One way to deal with this problem is to define a function subprogram with the 
same name as the array, that returns the specified array element from the 
original array, renamed as a one dimensional array. For example, in IBMF 

DIMENSION A (5, 10, 20, 3) 

X = A(I, J, K, L) 
would be translated to 

COMMON/B/B(3000) 

X = A(I, J, K, L) 
where A is defined by 

FUNCTION A(I, J, K, L) 

COMMON /B/B(3000) 

M = I- l+ 5* (J-1+10*(K-1+20"(L-1))) 

A = B(M) 

RETURN 

END 

For CDCF data initialization must be removed from type declarations (2.2, 3) 
and put in a separate DATA statement. 

GENERIC statements (2.2.4) must be deleted for CDCF, and the appropriate 
subprogram name inserted in all function and subroutine calls. 
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IBMF allows a parameter list on ENTRY statements (2.2. 5); CDCF does not. 
This problem can be solved in several ways. One solution that leaves the 
subroutine calls undisturbed is illustrated below. 


IBMF code 

SUBROUTINE SUB (W, X, Y, Z) 

(body 1) 

ENTRY SUBA (Y, X, U) 

(body 2 ) 

END 

« 

• , 

CALL SUB (A,B, C,D) 

CALL SUBA (B,A, E) 

CDCF code 

SUBROUTINE SUBT (W, X, Y, Z, U) 

(body 1) 

ENTRY SUBTA 
(body 2 ) 

RETURN 

END 

SUBROUTINE SUB (W, X, Y, Z) 

CALL SUBT (W.X.Y,Z,U) 

RETURN 

END 

SUBROUTINE SUBA (Y,X,U) 

CALL SUBTA (W, X, Y, Z, U) 

RETURN 

END 

List directed l/O (2.2.6) will have to be handled by a list scanning 
subroutine. 

Call-by-name for subroutine variables (2.2. 7) is taken care of in 
CDCF either by the LOC library function, or by making the variable 
a one dimensional array. 
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Real numbers in the IBM 360 are expressed in base 16 (hexadecimal notation). 

All have a 2 -digit exponent. The characteristics for REAL*4 (single precision), 
REAL*8 (double precision) and REAL*16 (extended precision) are 6, 14, and 
28 digits respectively. For most mathematical work, satisfactory precision is 
preserved if REAL*4 and REALMS variables are represented as single precision 
(REAL) variables in CDCF, while REAL'-16 are classified as double precision. 

No difficulty should arise if LOGICAL*! and LOGICAL*4 are replaced by 
LOGICAL; similarly for INTEGER*2, and INTEGER*4. Hexadecimal constants, 
on the other hand, can be expected to be involved in machine dependent operations, 
and will require manual translation. 

The input /output and data transfer statements of 2. 5 are more subtly machine 
and software system dependent. For example, the asynchronous read/write 
statements (2. 5. 1) in the two languages are quite similar and, except for the 
record skipping feature in IBMF, translation involves little more than syntax 
changes. It is not clear, however, that a CDC programmer and an IBM pro- 
grammer would resort to asynchronous operation at the same place and under 
the same circumstances in their respective programs. For the present, it will 
be assumed that the translator makes the translation, but inserts a warning 
flag that all might not be well. 

The situation with regard to the random access statements is similar, except 
that here translation is complicated further by the two languages specifying 
different parameters as well as different formats. Those statements probably 
should be flagged for manual translation. 

The conclusion that emerges from the above thicket of detail is that, while not 
eilways easy, machine translation of FORTRAN programs from one dialect to 
another is possible, provided that the translator can detect that translation is 
required. 

Machine dependent data and parameter values are most likely to occur in 
DATA statements 
FORMAT statements 
IF statements 
DO statements 
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integer assignment statements 
logical assignment statements 


and can be expected to require the most attention from the programmer to 
resolve. 

The translation process as it is presently conceived, proceeds in the following 
way. All programs are submitted with test data and the expected output. An 
attempt is first made to compile and execute the program without preliminary 
translation to determine adherence to IPAD programming standards. If the 
program fails to compile correctly, a preliminary examination of the error 
listing should be made to determine if translation will resolve the difficulty. 

(The error may be an untranslatable statement. ) 

If, after translation, the program compiles but fails to execute correctly, it 
can be assumed that the program contains machine dependent code. At this 
point, the programmer takes over, and begins a detailed examination of the 
suspected parts of the code aided by the IPAD compiler's cross reference 
listing. His editing comments are keypunched to create a correction deck for 
the program. in UPDATE (editor) format. The edited code is compiled, execution 
is attempted, and the cycle repeats until a correct executable program is 
obtained. 
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3.0 INTRODUCTION TO THE DEVELOPMENT OF A MACHINE 
INDEPENDENT FORTRAN 


3. 1 Preliminary Remarks 

One conclusion that emerges from an examination of both CDCF and IBMF is 
that neither language is appropriate for use as the machine independent' IPAD 
FORTRAN (IPADF). Both languages contain explicit machine dependent 
statement forms and, more important, statement forms they share in common 
are often given different interpretations by the respective compilers. 

The proliferation of FORTRAN dialects, of which the above two are examples, 
is caused by a number of factors, not the least of which is the "not-invented- 
here" syndrome. A less frivolous reason is that computer language development 
has been directed toward incompatible goals. While the language theorists 
sought to develop languages suitable for the machine independent description of 
algorithms, another and more influential group, wanted languages for practical 
programming use that allow the programmer to reduce the amount of detail he 
need write, and yet produce programs that execute satisfactorily on predeter- 
mined computers. The result was an odd compromise. The theorists specified 
nothing quantitative in languages designed primarily for numerical calculations. 
In fact, in the hope of preserving machine independence, they defined nothing • 
that was not, in some sense, common to all machines. The developers of 
practical languages merely added what they felt they needed either, explicitly 
to the syntax, or implicitly in the interpretation given by the compiler. 

The error of the theorists was in leaving so much undecided. What is not 
specified is left to the user to interpret as he sees fit, and each will avail 
himself of the freedom granted. A truly machine independent language will 
require more, not less, information than one intended for a single class of 
computer. For example, if the FORTRAN statement, C = A + B, is interpreted 
routinely as a 24-bit operation on one machine, and as a 48 -bit operation on 
another, the two computers are very possibly not working the same problem. 

The numerical precision with which an arithmetic process is carried out is 
generally crucial to its accuracy, and it is a fundamental shortcoming of a 
machine independent language if it is incapable of expressing this most basic 
of parameters. 
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In IPADP it is expected that the precision of real niimbers is to be specified 
by an explicit statement of the number of significant decimal digits desired; 
thus, BEALE'S, has s significant digits. There is to be no default option, and 
hence no REAL or DOUBLE PRECISION declaration. No penalty is expected if 
calculations are carried out with higher precision than required. The treatment 
of complex numbers is similar, and needs no separate discussion. 

The declaration INTEGER^S's specifies the number of decimal digit positions 
required, and is included for the sole purpose of aiding the compiler in deter- 
mining storage requirements. 

Integers expressed to bases other than 10 constitute a special class, denoted 
by the declaration BASE’J'n. s, where n is the base and s is the number of base 
n digits. Logical constants have a fixed length and require no additional 
specification. 

A similar sort of vagueness plagues most FORTRAN dialects with respect to 
their character set, or alphabet. Few dialects have common alphabets, or 
order them the same way, ANSI standards notwithstanding. Even when the 
sets more or less agree, they are often partitioned into subsets differently. - 
For example, IBMF counts "$" as an alphabetic character; CDCF, as a special 
symbol. Clearly, IPADF must either (i) speeify once and for all what its 
character set is, how the symbols are to be classified, and in vdiat order they 
are to be ranked (collating sequence), or (ii) this information must be provided 
explicitly with each program requiring it. It is expected that the first of 
these alternatives will be adopted for IPADF. 

Packing and masking operations occur frequently in FORTRAN programs, and 
almost invariably are machine dependent involving an addressable unit, usually 
a machine word, capable of storing n characters of the alphabet, where n is 
a machine dependent parameter. It seems likely that the requirements for 
machine independence will make it necessary to introduce a type LITERAL^'s 
declaration to define the number of characters in the addressable unit. 

Because every variable must be given an explicit length declaration in IPADF, 
the default rules for implicit typing must be dropped. However, the IBMF 
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IMPLICIT type *s declaration will be retained to provide blanket typing, except 
that the length specification s, optional in IBMF will be mandatory in IPADF. 

It is tempting to consider a general overhaul of FORTRAN mixed mode arithmetic 
for IPADF, since different dialects often produce different results for simple 
arithmetic statements involving mixed real and integer operands. At the very 
least, arithmetic operations involving non-numeric variables should be disallowed; 

For the IPAD environment, it is undesirable that run-time specifications appear 
in the body of a program. Specification of overlays, for example, would have 
to be deleted, or ignored, if the program is to execute on a virtual address 
computer. Leaving aside development of a machine independent job control 
language as visionary at present, it would appear that the best solution for IPAD 
is to require that all run-time information be provided on printed forms for 
operator use in constructing the job control deck for the host computer. 

The above discussion applies primarily to so-called third generation computers 
in which instructions usually involve one operation per instruction, the most 
notable exception being block transfers of data. Fourth generation computers are 
distinguished by a capability to perform arithmetic and logical operations on 
all or a selected subset of the elements in a one dimensional array or vector. 

It turns out that very little modification of the FORTRAN language is required 
to permit elementary vector operations. The usual convention is that the name of 
a one dimensional array represents the array in an arithmetic or logical expression, 
while a vector in a higher dimensional array is selected by replacing the index 
of its elements by a * in its indexed name. For example, if DIMENSION A(10, 20), 
B(10) then B = A{*, 5) means that the fifth column of A is transferred to the 
vector B. 

A proposed machine independent IPAD language incorporating the features 
discussed above is sketched briefly in the following paragraphs. 
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3.2 IPAD FORTRAN (IPADF) 


The character set of IPADF are the 2 6 letter symbols A-Z, the 10 digit symbols 
0-9, and the special symbols - + - ^ / { ) , . $ ; Letter and digit symbols are 
called collectively alphanumeric symbols. 

Names begin with a letter and can contain up to 7 alphanumeric symbols. Varia- 
bles are identified by name and declared by type and length. The following types 
are recognized by IPADF: REAL, COMPLEX, INTEGER, LOGICAL, BASE, 
LITERAL. For real and complex numbers, the length is the minimum number 
of significant decimal digits in the fraction part of its floating point representa- 
tion. Logical variables are of constant length and require no specification. 

For all the remainder, the length specifies the maximum number of elements 
denoted by the variable, for integers, decimal digits; for base variables, 
the number of base a digits; and for literals, the number of characters. Type 
REAL. COMPLEX, INTEGER, and LITERAL follow the form 
type *s name^, name 2 » • . . 

where s is the length. Based variables are declared by 
BASE *n. s name^, namcgj • • • 

where s is the maximum number of base n variables (octal, hexadecimal, etc. ) 

For logical variables 

LOGICAL name^, namcg, . . . 
is sufficient. 

Arrays may have up to 7 dimensions and are declared in a dimension statement 
of the form 

DIMENSION Array name (d-, d„, ..., d ) 

JL ^ H 
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Arrays can be referenced in a number of ways. An array name, standing alone, 
denotes the whole array. An array name followed by coordinate variables, 

A(I, J, K) picks out an element in the array, while A(=^=, J) designates the Jth 
column vector in the array A. 

There are no default type declarations. However, the IMPLICIT declaration 
allows variables to be typed by their initial letter . The statement form is 
IMPLICIT type *s 

followed either by the' specific letters involved, or by their range (e.g. I-N). 

Arithmetic operations involving variables of different type is called "mixed 
mode arithmetic. " The results of valid IPADF mixed mode arithmetic operations 
are shown in Table (3. 1) below. 



Real 

Complex 

Integer 

Logical 

Base n 

Literal 

Real 

Real 

Complex 

Real 

— 

Real 

— 

Complex 

Complex 

Complex 

Complex 

— 

— 

— 

Integer 

Real 

Complex 

Integer 

— 

— 

— 

Logical 

— 

— 

— 

Logical 

— 

— 

Base n 

Real 

— 

— 

— 

Base n 

— 

Literal 

— 

— 

— 

— 

— 

— 


Table (3. 1) Mixed Mode Arithmetic 

Definition of IPADF assignment statements follow normal FORTRAN rules 
except for the restrictions imposed on mixed mode arithmetic shown above, 
and the extension of the notion of variable to include vectors as well as scalars. 
Thus, if A, B, and C have been dimensioned as N element one dimensional 
arrays, C = A+B, has the same meaning as:. 

DO 1 I = 1, N 
1 C(I) = A{I) + B(I) 
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Run time declarations are not permitted in IPADF. Directions for segmenting 
memory, definition of overlays and input /output files, etc. are relegated to the 
job control language. 


In general features common to both CDCF and IBMF are retained in IPADF. 

For unshared features, the decision on which to incorporate and which to reject 
is based on estimated ease of coding in a machine independent environment, a 
purely subjective judgement. This list below is not complete, but covers most 
of the differences between CDCF and IBMF noted in Section 2. 


(3.2. 

1) 

(3.2. 

2) 

(3.2. 

3) 

(3.2. 

4) 

(3.2. 

5) 

(3.2. 

6) 

(3.2. 

7) 

(3.2. 

8) 

(3.2. 

9) 

(3.2. 

10) 

(3.2. 

11) 

(3.2. 

12) 


ENCODE-DECODE is not implemented 

Implied DO -loops in DATA statements are permitted 

Data initialization in labeled COMMON is allowed outside a 
BLOCK DATA subprogram 

Two branch arithmetic and logical if statements are not allowed 

Literal and Base n constants can appear in arithmetic statements 
subject to the rules of mixed mode arithmetic 

Masking expressions are not permitted 

Abbreviated subscripts on arrays, and abbreviated logical 
symbols are not permitted 

Left and right justified literal constants are permitted, but 
with blank fill. 

Data initialization is confined to DATA statements 
No GENERIC statement 

Dummy variables are permitted on ENTRY statements, 
following IBMF rules 

List directed l/O not implemented 
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3. 3 FORTRAN Dialect to IFADF Translation 


For the implementation of Method 1, it is necessary that OM's written in each 
of the m FORTRAN source dialects, L., be translated into L^, the common 
IPAD FORTRAN. (IPADF). 

It will be assumed that the translator Tj^^ is written in though, of course, 
this is not necessary; any language at the source installation will do. The 
main point is that each source user is expected to develop and checkout his own 
translator, and convert his own OM's. The complete process is depicted 
schematically below. 


(1) compile -translator on source computer 


h'>- 


P(C^, M^) 


P(T. ,M, ) 

LO' 1 


(2) translate test program A 


P(A,L.) 


P(Tjo,M^) 


— «>P(A,L ) 
o 


(3) compile test program on source computer 


P(A, L. ) 


P(C^,M.) 


>P(A,M.) 


(4) execute test program on source computer 
D — ►! P(A, I — 8» Rc 


(5) compile translated test program on host computer 


P(A,L^)- 


P(C .,M.) 
oj 2 


P(A,M.) 

3 


(6) execute test program on host computer 

I— ^R. 


D- 


P(A,M.) 




(7) compare results Rg and from steps (4) and (6) respectively. 


The validation process was described in some detail to direct attention to the 
fact that final certification of each translator will have to be made on a host 
computer. Initial translator checkout and translation on source computers is 
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proposed here to distribute the workload more evenly, but this approach involves 
considerable travel between source and host installations until checkout is com- 
pleted. The alternative is to perform all translation on the host computers. If 
the workload permits, this may be the better way. A final decision cannot be 
made at this time. 

Translation from source dialects to IPADF is mainly a matter of removing 
machine dependent code from OM's. Some of this code can be expected to 
satisfy the syntax rules for both languages, and will be impossible for a trans- 
lator to detect. An example of this type was given in Section 1. 6. 

Each installation is responsible for its own OM translation, and, consequently, 
is free to develop whatever aids it chooses for the purpose. However, it is 
expected that most will find it useful to incorporate into the translator the 
capability for flagging sections of code having a high probability of being 
machine dependent. Particular attention should be given to: 

(3.3.1) DO-loops involving integer variables 
(3. 3.2) Logical IP statements 

(3. 3. 3) Non-standard library functions operating on characters 
(e. g. , SHIFT, PUT, GET, etc.) 

(3.3.4) DATA statements containing binary, octal or hexadecimal data 
(3. 3. 5) FORMAT statements (non-standard, literal) 

Hand corrections to programs will normally be made via the installation's 
standard editing program (e. g. , CDC UPDATE). Pinal validation of an OM 
will require comparison of its output with that obtained from the untranslated 
program, and for some cases, it can be expected that several passes through 
the translate-correct-edit loop will be necessary. 

3. 4 IPAD Implementation Language 

Implementation strategies were discussed briefly in Section 1. 6, and the con- 
clusion was reached that the implementation language for IPADF should itself 
be machine independent. One language description will suffice then for all IPAD 
users Involved in the development of IPADF, and if the implementation language 
is one for which a compiler is generally available, it remains only to determine 
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its suitability for the task. 


The main operations performed by a compiler are (i) parsing of the statement 
symbol strings to separate the fixed and' variable parts and establish the pre- 
cedence of operations, (ii) conversion of constants and data to internal machine 
representation, (iii) allocation of storage to variables by name and type, and 
finally (iv) generation of the machine language code. 

There is no obvious reason why algorithms performing each of those operations 
cannot be described satisfactorily in FORTRAN, augmented, as necessary, by 
the addition of library subprograms. Call this implementation language, IMPF. 
The principal advantage of this approach is that, if care is taken to keep machine 
dependent code out of the program itself, IPADF and its successor for fourth 
generation computers, IPADFV, can be written in IMPF for each host computer 
and compiled by its standard FORTRAN compiler. 

It is not intended that the compiler itself be machine independent. Much of the 
code could be made so, but at exorbitantly high cost. Very likely it would be 
necessary to settle on FORTRAN character as the information unit, and store 
data one character per machine word. Every variable name in the symbol table 
would then be .represented by an array, named by a pointer variable. Storage 
allocation strategies would have to be made uniform, and this could cause 
undesirable system repercussions. Then, too, it would be desirable to translate 
the FORTRAN statements to an intermediate language so that the only machine 
dependent operation was the final generation of machine code. It is unlikely 
that very efficient compilers would result from an approach subject to so many 
restraints. 
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4.0 MIGRATION OF OM»S FROM THIRD GENERATION TO FOURTH • 
GENERATION COMPUTERS 

4. 1 Introduction 

A rudimentary capability for expressing vector operations is incorporated in the 
proposed design for IPADF. More extensive features are required for fourth 
generation computers such as Control Data's STAR-100, which can perform 
arithmetic and logical operations on character and bit strings, as well as normal 
and compressed (sparse) vectors. 

For concreteness, STAR will be taken as representative of fourth generation 
computers, and a brief sketch of its salient features will be useful. 

48 

STAR is a virtual address computer able to distinguish 2 distinct address bits. 
These addresses are automatically converted by the instructions using them into 
bit, byte, half-word or full-word addresses. The central memory consists of 
500,000 full words of core storage, and a high speed register file of 256 words. 
Arithmetic operations are carried out on either 32 -bit half-words or 64-bit full- 
words in either scalar or vector mode. 

Vector operations can be performed on normal or sparse vectors. A normal 
vector is just an ordered list of half-words or full-word elements. A sparse 
vector is a vector formed by application of a binary mapping function, or order 
vector, that extracts in order a subset of elements from the original vector. 

When arithmetic operations are performed on sparse vectors, these elements of 
the original vector not appearing in the sparse vector are taken to be zero. 

In addition to the standard arithmetic and logical operations, a comprehensive 
set of macro and APL functions (c. f. Iverson? are implemented such as contract, 
expand, merge, mask, element sum, element product, maximum element, 
minimum element, vector dot product, search, and select. 

4. 2 IPADF Extended For Vector And String Processing (IPADFV) 

Part of the usefulness of FORTRAN is that programs in it are shorter and more 
readable than if written in a computer's assembly language. To preserve this 
feature for fourth generation computers, it will be necessary to extend the 
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capabilities of the language to encompass the more sophisticated Instruction 
repertoire of these machines. This can be done in two ways: by enlarging the 
syntax, or by creating new in-line functions. 

In fact, both methods will be found to be useful. Certainly, new declarations 
will be needed to accommodate the new variable types, and logical fitnctions 
extended over all the members of an ordered set will require quantifiers in 
addition to the standard Boolean functions. On the other hand, many of the 
macro and APL instructions in STAR can be implemented easily and efficiently 
by in-line functions. Probably, frequency of use and readability should be the 
criteria for deciding whether an operation should be represented by an in-line 
function or by a new statement form. Elements in a function argument list tend 
to be anonymous, particularly when they can be distinguished only by their 
position in the list. The alternative is not always better - witness the -bewildering 
array of infix operators in APL. 

Fourth generation computers are distinguished from third generation machines 
primarily by their capability for processing lists efficiently. In the computer, a 
list is just a consecutive set of storage locations, and is defined by a starting 
location and the number of elements contained in it. From the programmer's 
point of view, the meaning assigned a list depends on how it is to be used. For 
example, a list A can represent (i) an n-dimensional vector A (with ith component 
Aj^) which enters as single variable in a calculation f(A,b, c, . . . ) or (ii) the set 
of values of. a single variable a, whose typical element a. is the value of a in 
in the ith calculation of f(a^, b, c, in) for i = 1, 2, . . .n. Often a list contains 
logically distinct sublists which are extracted to become new lists in subsequent 
operations. 

The case for which the elements of a sublist form an arithmetic progression in 
the master list occurs often enough to justify a special notation of the form 

B = A{Mj^ : M2 :Mg) 

where B is composed of those elements of A whose indices i satisfy the inequality 
Mf + Mg (i - 1) ^ Mg. More generally, IPADFV allows any of the following 
forms to apply as well to the component vectors of an array. 
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(i) 

Mj^ : Mg : Mg 

(ii) 

Mj :Mg 

(iii) 

OO- - 

■'r* 

(iv) 

Mj ; * : Mj 

(v) 

Mr’* 


Here and Mg have the value 1 when omitted. The symbol * denotes that 
has the value of the dimension length. For example, if 

DIMENSION A (20), B(10, 6) 


then 

A(3 : 18 : 7) represents A(3), A{10), A(17) 

B(2 : * : 6, 4) represents B(2, 4), B(8, 4) 

Reference to sparse vectors in IPADFV have the general form , where 

V is the vector from which the elements were obtained, and L is a logical vector 
specifying which elements of V occur in I^ . Subscripts can appear on 

either V or L , and follow the rules given above. For example, 

jy(I:J), L(50:100j 

The logical operators 


. NOT. negation 

. OR. alteration 

. XOR. disjunction 

. AND. conjunction 

of IPADF which can take either vector or scalar arguments is extende.d in IPADFV 
by the unary logical vector quantifiers 

. ALL. L universal conjunction of all elements of L 

, ANY. L existential alternation of all elements of L 

. NONE.. L universal negation denial of all elements of L 


Logical expressions are evaluated by scanning from left to right with precedence 
of logical connectives established by 
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• ANY. 


. NONE. 


.NOT. 

.ALL. 

.AND. 

. OR. . XOR. 

If L is a scalar logical variable, the .ALL. L and .ANY. L reduce to L, 
and .NONE. L reduces to .NOT. L. 

A relational assignment statement is introduced in IPADFV of the form 
P = Q. R. S 

where Q and S are vectors, and R is one of the relations 

.EQ. .NE. .GE. .LT. 

Execution of this statement leads to three different results depending on the type 
of P. If P is an integer variable, P is assigned the index of the first elements 

of Q and S to satisfy the relation R. If P is an integer vector, each element 

of Q is compared with successive elements of S, and whenever the relation R 
is first satisfied, the element of P corresponding to the element of Q is 
assigned the index of S. If P is a logical vector, each element of P is set to 
. TRUE, if the corresponding elements of Q and S satisfy R; otherwise, 

. FALSE. 

The scalar (dot) product C of two vectors A and B is simply 
C = A*B 

The notation 

B = +A 
and C = -A 

where A is a vector and B is a scalar, denote the sum and product of the 
elements of A, respectively. 

In addition to the extensions of the IPADF syntax noted above, the set of in-line 
functions is enlarged in IPADFV to include most of the STAR macro and APL-like 
instructions. These include; 
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MERGE (A, Z, B) selects an element from vector A or vector B, 
depending on whether the corresponding element value in logical vector 
Z is .TRUE, or .FALSE. No elements of A or B are skipped. 

MASK (A, Z, B) selects an element from vector A or vector B, 
depending on whether the corresponding element value in logical 
vector Z is . TRUE, or .FALSE. The element not selected is 
passed over. The symbol * in either vector position indicates 
that no selection is made if the element normally selected would 
have come from the vector in that position. For example 

MASK {A, Z, * ) is equivalent to selecting an element 
of A whenever the corresponding value of Z is . TRUE. , 
while (*, Z, B) selects an element of B whenever the 
corresponding value of Z is . FALSE, 

4.3 IPADF To IPADFV Translation 

The principal problem for IPADFV, the fourth generation FORTRAN, for IPAD 
is the same as for its predecessor, IPADF, namely to preserve machine inde- 
pendence. Clearly, the introduction of list parameters (vectors, strings, etc. ) 
in fourth generation computers does not of itself aggravate the situation unduly 
since the same length prescriptions can be applied to the elements of a list as 
to individual variables. What must be taken into account is the near certainty 
that during the lengthy transition phase from third to fourth generation processors, 
the IPAD host computers will be a mixed bag - some belonging to one class and 
some belonging to the other. Nevertheless, if machine independence is to be 
preserved, the OM's written in this period should execute on all host machines, 
though it is unreasonable to expect them to execute on all with the same efficiency. 
This concern for linking third to fourth generation computers was the prime 
reason for introducing elementary vector operations in IPADF. For a third 
generation machine, the definitions are little more than abbreviations for simple 
DO loops. For a vector processor, each represents a basic machine operation. 

It follows from considerations such as the above that the shift from IPADF to 
IPADFV should be delayed until fourth generation machines are IPAD standards. 


Ca9 



As the migration from third to fourth generation processors progresses, it will 
become necessary to decide in the case of individual OM's whether to reprogram 
or not. The incompatibility in structure between vector and conventional com- 
puters is reflected in the programs written for them. 

An example illustrating this point is the discrete Fourier transform defined by 

n-1 

(4.1) f(u) "" I] g(v)exp{-27Tiuv/n) u = 0, 1, . . . , n-1 
v=0 

where f(u) and g(v) are suitably chosen complex functions of the integer variables 
u and V, and is a basic tool in the analysis of complex wave forms, so that much 
effort has gone into the search for efficient procedures for making the calculations. 
The most successful of these have come to be called Fast Fourier Transform 
(FFT) algorithms, and all depend upon some form of factorization of the exponent. 

When the sample size n is a power of 2, n=2™', the execution time on a digital 
computer is reduced in this way to approximately the fraction m/n of that 
required by direct calculation. 

The STAR algorithm consists of two parts. In part 1, the n/2 sine and cosine 
terms are calculated by an application of the polynomial evaluate (DE) instruction 
which performs a power series expansion 

y^ = Uq + a^Xj^ + agx^ + '. . . + a^x^ k = 0, 1, . . . , n-1 

Part 2 is the main loop, executed m times. The calculations of (4. 1) are carried 
out by 10 instructions operating on vectors of length n/2 followed by a merge of 
the upper and lower halves of the real and imaginary components, respectively. 
This step is required to position elements x(0), x(l) and y(0), y(l) n/2 postions 
apart for the next stage. That it does so is easily seen, since at stage k, the 
matching elements for stage k + 1 are n/4 postions apart. The merge moves 
ail elements a, , k <n/2, to a! and all elements a, k>n/2 to a'. , 

K J K ] 

s-1 s-1 ^ 

where j = 2k (mod n) - k(mod 2 ), and = j + 2 . Then if, j = i + n/4 it 

follows in either case that j’ - i' = n/2. 

Finally, a compression instruction followed by a merge instruction replaces 
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every other group of Length s in the sine and cosine lists by the group' just 
preceding it. 

Besides eliminating the final sort required by most FFT algorithms, the pro- 
cedure described above eliminates memory bank conflicts when (as in STAR) 
the number of banks is a power of 2. 

The main loop of the FFT program written in IPADFV is given in Figure 4-1 
below. All functions are in-line and represent single STAR instructions. 


100 UO = YO + Y1 
U1 = YO - Y1 
YO = XO + XI 
Y1 = XO - XI 
XO = Y1 - COS 
XI = Y1 - SIN 
E = U1 - SIN 
Y1 = XO + E 
E = U1 - COS 
U1 = XI + E 
X = MERGE (Y0,Z,Y1) 
Y = MERGE (U0,Z,U1) 
U = MASK (COS,Z, *) 
COS = MERGE (U,Z,U) 

U = MASK (SIN, Z, 

SIN = MERGE (U,Z,U) 

Z = BIT (Z,Z) 

N = N - 1 
IF(N) 110, 110, 100 
110 CONTINUE 


Figure 4-1. FFT Main Loop (Vector) 
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A FORTRAN version for the same algorithm, but for a conventional computer is 
given in Figure 4-2. The above subject was discussed at some length to empha- 
size the critical point that, while software migration from local FORTRAN 
dialects to IPADF (or its extension, IPADFV) will permit execution on either 
third or fourth generation host computers, hand reprogramming will be required 
if the full potential of a vector computer is to be realized. 


DO 2 PASS=l,N4POW 

NXTLTH=2 =f==i'(N2 POW-2 =i=PASS) 

LENGTH=4*NXTLTH 

SCALE=6. 283185307/FLOAT(LENGTH) 

DO 2 J=1,NXTLTH 
ARG=FLOA T( J- 1 )*SCALE 
Cl=COS(ARG) 

S1=SIN(ARG) 

C2=C1*C1-S1-S1 

S2=C1*S1+C1*S1 

C3=C1*C2~S1*S2 

S3=C2*S1+S2=4=C1 

DO 2 SEQLOC=LENGTH, NTHPOW, LENGTH 

Jl=SEQLOC-DENGTH+J 

J2=J1+NXTLTH 

J3=J2+NXTLTH 

J4=J3+NXTLTH 

R1=X(J1)+X(J3) 

R2=X(J1)-X(J3) 

R3=X(J2)+X(J4) 

R4=X(J2)-X(J4) 

Il=y(Jl)+Y(J3) 

I2=Y(J1)-Y(J3) 

I3=Y(J2)+Y(J4) 

I4=Y(J2)-Y(J4) 

X(J1)=R1+R3 

Y(J1)=I1+I3 

IF(J.EQ. 1) GO TO 1 

X(J2)=C1-(R2+I4)+S1*(I2-R4) 

Y(J2)=-S1-(R2+I4)+C1-(I2-R4) 

X(J3)=C2*(R1-R3)+S2*(I1-I3) 

Y(J3)=-S2«(R1-R3)+C2 =5^(11 -13) 

X(J4)=C3-(R2 -I4)+S3*(I2+R4) 
Y(J4)=-S3-(R2-r4)+C3*(I2+R4) 

GO TO 2 

1 X(J2)=R2+I4 
Y(J2)=I2-R4 
X(J3)=R1-R3 
Y(J3)=I1-I3 
X(J4)=R2-I4 
Y(J4)=I2+R4 

2 CONTINUE 


Figure 4-2. FFT Main Loop (Scalar) 
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